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LIBC は X 68000 および X 68030 上の Human 68 k ver .2， Human 68 k ver .3 上で動作 
しますが， GCC あるいはがすでに動作していることが必要です。したがって ， GCC 
を利用する場合には最低限 2 M バイトのメモリが必要です。 

本書は， r X 680 x 0 Develop . &: libc II j の内容に即して r X 680 x 0 libcj を加筆修正し 
たものです。 

バージョンアップによって仕様変更されたライブラリ関数については，新規に作成した 
「変更」項目にその内容が解説してあります。 


• システム名， CPU 名などは一般に各社の登録商標です。本文中では，とくに TM , ⑰は明記しておりま 
せん。 


©1994 本書の内容は著作権法上の保護を受けています。著者，発行者の許諾を得ず，無断で 
転載，複製することは禁じられております。 




はじめに 


「 X 68 k Programming Series #2 X 680 x 0 libc 」 は， Human 68 k と UNIX 
という OS の違いを吸収し，他の処理系と X 68000 の間でプログラムの移植性 
を高めるために作成されたライブラリです。また， SHARP 純正の ATC との互換 
性を考慮してコンパチブルヘッダも付属していますから，^7ライブラリを前 
提として作成されたプログラムとも， ソース レベルで互換性を保つことができま 
す。そのほかにも，ユーザの環境に合わせて数値演算コプロセッサを直接駆動す 
ることができる数学関数や UNIX ライクなシグナル機構など， X 68000 のもつ 
機能をこれまでよりもいっそう発揮できるような関数群を備えています。 

LIBCity 「 X 68 k Programming Series 」 の 「#2 X 68000 Develop.j で提供さ 
れている開発ツールを使用して作成されています。そのため，これらのツールと 
合わせて使用することによって，より高度なプログラム開発を行うことができる 
ようになるでしょう。また，ライブラリの全ソースコードが公開されているだけ 
ではなく，ほとんどの関数が C 言語によって記述されていますから， ユーザの 皆 
さん自身の手でライブラリのメンテナンス•カスタマイズ • 機能追加などを容易 
に行うことができます。 

LIBC が X 68000 および X 68030 の世界を広げることに少しでも役立つこと 
ができれば幸いです。 


1993年3月 


Project LIBC Group 


Manual Books 発刊へのまえがき 


前著 r X 68 k Programming Series #2 X 680 x 0 Jibe 」 を発行したのが 1993 年 5 
月のことでしたから，それからちょうど1年近く経ったでしょうか。最初に発表 
することができたバージョン 1.0.20 も，その後，改版を続けて1994年7 
月現在ではバージョン 1.1.31 にまでいたっています。 

フリーウェア（事実上は PDS ) としてソースコードまですべて公開したことも 
あり，思った以上にさまざまな反響をいただきました。不具合の修正や報告を， 
バソコン通信あるいは各種のネットワークを通じていただいたことも数多くあり 
ます。また，新たな追加機能を contribute していただいたこともありました。今 
や LIBC は ，これら多くの方々の協力がすべて結集したものになっているといえ 
るかもしれません。 

さて，本書 「 X 680 x 0 libc Manual Booksj を作成するにあたり，旧版から変 
更された部分などの相違については， r X 680 x 0 Develop . &: libc Ih で紹介した 
内容を完全に反映させるよう心がけました。したがって，マニュアル版ではかな 
り今現在のの仕様に忠実なものとなっています。しかし LIBC はこれから 
も成長していくでしょうし，提供する関数の数も増えていくでしょう。その意味 
では，マニュアルと実物とで仕様が異なる関数も出てくると予想されますが，そ 
れについてはあらかじめご了承していただきたく思います。 

最後に，この場をお借りしてあらためて協力してくださった多くの，実に多く 
の方々にお礼申し上げます。 ANSI C 対応をうたってはいるものの，正直いって 
どちらかというと UNIX 寄りである「特殊な」ライブラリにもかかわらず支持 
してくださっている皆さん，不具合を報告/修正していただいた皆さん，そして新 
たなソースコードを送ってくださった皆さん，どうもありがとうございました。 


1994年7月 


Project LIBC Group 
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Chapter 1 


LIBC リファレンス 


実際にライブラリを使い始める前に， 116(7 について少し説明しておき 
たいと思います。 LIBC は ZC に代わるものではありませんし，すべての 
場合に役に立つわけではありません。 LIBCi ： の関係やそれぞれの得 
手不得手を知っておいてください。 

また，のインストール手順やインクルードファイル，ライブラリ 
ファイルの使い方についても解説します0 






























































































































































































































ライブラリー第 1 部 



❖インストールの準備 


LIBC はパソコン通信上などでパッケージとして配布されています。これらの 
パッケージにはそれぞれインストールプログラムが付属しています。ここではそ 
のインストールプログラムの使い方を解説します。実際にを入手して，イ 
ンストールする際に参考にしてください。 

なお一例として， L 你¢7はパソコン通信 NIFTY - Serve の SHARP Users ’ フォー 
ラム.ワークステーション館 ( FSHARP 3) のデータライブラリに登録されてい 
ます。 

実際にインストールをする前に，ディスクと環境の準備が必要です。説明をよ 
く読んで，インストールに備えてください。 

L / Z?C は2つのパッケージで構成されて 
います。1つはライブラリパッケージで， 
実際に L 你 C を利用するためのインクルードファイルやライブラリファイルが含 
まれます。もう1つはソースコードパッケージで，のすベてのソースコー 
ド，付属資料などライブラリパッケージに含まれないものすべてが入っています。 

これら2つのパッケージのうちライブラリパッケージは必ず必要ですが，ソー 
スコー ドハ。 ッケージはサイズが非常に大きいため，イ ンス トールするかどうかは 
あなたが選択できるようになっています。それぞれのパッケージは概算で Table 
1-1 に示されるだけのディスク容量を必要とします。 

Table 1-1 で作業領域とあるのは，インストール時に一時的に使用するディス 
ク領域です。インストール完了後はこの作業領域は必要なくなり，インストール 
容量で示された容量だけを占有します。したがってライブラリパッケージをイン 
ストールするには，最低限 2 M バイトのメモリと約 1 M バイトのディスク容量が 
必要になります。これはフロッピーディスクでも不可能ではない大きさですが， 


Table 1-1 •インストールに必要なディスク容量 


パッケージ名 

作業領域 

インストール容量 

ライブラリパッケージ 

1 M バイト 

1 M バイト 

ソース コー ドノ、。 ッ ケージ 

4 M バイト 

3.5 M バイト 


♦ ディスクの準備 
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できればハードディスクか'望ましいでしよう。もちろんソースコードハ°ッケージ 
のインストールには，ハードディスクが必ず必要となります。 

もし残りディスク容量がここで示した容量に満たない場合は，インストールプ 
ログラムが警告を表示して処理を中断します。 


のインストールを行う際には，特 
別環境を設定しなおす必要はありません。 
GCC なり ZC が動作するだけの環境 1 )が整っていればかまいません。 

ただし，ソースコードパッケージをインストールする場合は，環境を整える必 
要があります。ソースコードハ。ッケージ中のファイルのなかには，非常に長いファ 
イル名のものもあるので，そのままインストールするといくつかのファイルが重 
複して消えてしまいます。これを防ぐためには，ソースコードパッケージをイン 
ストールする前に，ファイル名を21文字すベて認識させるよう，環境を設定し 
なければなりません。 

もしあなたが Human 68 k ver .2， ver . 3を使っているならば ， “TwentyOne . X ” 
というフリーウェアが利用できます。しかし， Human 68 k ver . l を使っている 
場合は，残念ながらいくつかのファイルが失われる可能性があることを黙認し 
なければなりません 2 )。 “ TwentyOne . X ” の設定方法やインストールについては， 
LIBC のイ ンストールの説明でもう一度触れますので，このまま読み進んでくだ 
さい0 


♦ 環境の準備 


1) 環境設定については， 
GCC や XC のマニュァ 
ルを参照してください。 


2) したがって ，自分で LIBC 
のライブラリを再構築す 


ることはできません。 


♦> インストールする 


準備はもう整ったでしょうか。それではいよいよインストール作業に入ります0 
説明をよく読んで，まちがいのないように気をつけてください。 


- 1 まず X 68000 なり X 68030 の電源を入 

♦ 起動する 

_ I れ，あなたが普段使っている環境で立ち 

あげます。フロッピーディスクだけで使用している人は，そのシステムディスクか 
ら，またハードディスクを使っている人はそのハードディスクから Human 68 k 
を起動してください。また，あなたが SX - Window を使っているのならば， 
SX - Window を終了させてコマンドラインに戻るか， “ C 0 MMAND . X ” のアイコン 
をダブルクリックしてコマンドシェルを起動してください0 
次に，ダウンロードしたアーカイブを納めたディレクトリにカレントディレク 
トリを変更してください。たとえば “ C :\ ARCHIVE ” ディレクトリにパッケージ 
ファイルを格納してあれば，次のようにタイプします。画面の表示例中の “ AA >” 
という部分は Human 68 k のプロンプトです。 
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A:\> C:\ARCHIVE 


最後に，そこから“ SETUP . X ” を起動します。次のようにタイプしてください。 


C:\> SETUP. X 


正しく “ SETUP . X ” が実行されると，画面 
にインスト ー ルプ ログ ラムのメ ッセー ジ 
が表示されます。基本的なインストールの方法は非常に簡単なもので，画面に表 
示された質問に答えていくだけです。以下，順を追って説明していきます。質問 
の意味をよく理解して，正しく答えるようにしてください。 

なお，画面の表示例中の CTRL+C とは， [CTRL I キーを押しながら I C ] を押すこ 
とを表します。 


♦インストールを始める 


ネ本本ホ**本本本本本本本本氺本本ホ本本本氺本本本本本本本本本本本木本本本本本本本本本本本本本本木本本本本氺本木木本本本本 

* LIBC - Project C Library Group - Install Script * 

本本本*本本本本本本本本*木本本本本本ホ本幸本本本本本木ホ幸本本本本本本本幸本本本本幸本本本本本木本本本本本本木本本木本木 


今から LIBC をインストールします。質問に正しく答えてください。 

(質問） 

LIBC のパッケージのうち，どれをインストールしますか？ 

<1> ライブラリパッケージ（作業用に 1MB 必要です） 

<2> ソースコードパッケージ（作業用に 4MB 必要です） 

<3> 両方のパッケージ （作業用に 5MB 必要です） 

1,2,3 のどれかを選択してください。 

中断するには CTRL+C を押してください。 

(回答） 一 > 

まずイ ンス トールするパッケージを選択してください。この選択をする前に 
ハードディスクのどのディレクトリにイ ンス トールするか，またそのディレクト 
リの空き容量が十分にあるかどうかについて調べておいてください。 

それでは <1>番を選んだ方は 次の 「ライブラリ パッケージのインス トール」 
( P .5) を，<2>番を選んだ方はその 次の「ソースコードパッケージのインス ト ー 
ル」 （ P .10) を，<3>番を選んだ方は両方を読み進んでください。両方を選んだ場 
合は，まず ソースコードパッケージの イ ンス トールから始まります。 
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❖ ライブラリパッケージのインストール 


本セクシヨンではインストールプログラムのメッセージにしたがって ， LIBC 
のライブラリパッケージをインストールする手順について説明します。 

まずインストールするディレクトリを指 
定してください。インストールプログラ 
ムは指定されたディレクトリにすベてのデータをインストールできるかどうか， 
空き容量をチエックし，十分な空きがあればインストールを開始します。 


♦ インストール先の指定 


(質問） 

それでは「ライブラリパッケージ」をインストールします。 

どこにインストールしますか？デイレクトリ名で答えてください。 

中断するには CTRL + C を押してください。 

(回答）一-> 


たとえば“ A ， ドライブの “\ usr \ lang ” というディレクトリにインストールし 
たいときは，次のようにタイプしてください。 


(回答）- > A :\ usr\lang 


ここで，もしディスクの空き容量が足りない場合は次のようなメッセージが表 
示され，インストールプログラムは中断します。インストールするディレクトリ 
をもう一度確かめてから，インストールを最初からやり直してください。 


(警告） 

指定したディレクトリには「ライブラリパッケージ」を 
インストールするだけの空き容量がありません。 

もう一度確認して最初からインストールをやり直してください。 

C:\> 


ディスクの空き容量の確認が終わると，インストールプログラムはパッケージ 
のインストールを開始します。約2, 3分かかりますから，お茶でも飲みながら 
しばらく作業を見守っていてください。 
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それでは「ライブラリパッケージ」をインストールします。 

include/ 
include/a_out.h 
include/a • 丄丄 oca. h 
include/assert.h 


中略 

README 

WARNING 

インストールは無事終了しました。 
C :\> 


の標準構成では，すべてのライブ 
ラリが “. a ” 形式に統一されています。 
もしあなたが ZC に付属している “ LIB . X ” をもっているならば，これらをより高 
速な ver .2 の“.1”形式に変換することができます。 

“•1”形式のライブラリのほうが高速にリンクできる 


♦ ライブラリ形式の選択 


(質問） 

ライブラリの形式を高速な.1形式に変換しますか？ 
変換するなら n y "を 
変換しないなら" n " を 
選択してください。 

中断するには CTRL + C を押してください。 

(回答） 一 > 


“ y ” を選択すると，インストールプログラムはあなたの環境のなかから “ LIB . X ” 
を探し，それを使ってライブラリを“ .1” 形式に変換します。もし“ LIB . X ”が見 
つからなければ，インストールプログラムは次のようなメッセージを表示し，名 
称の変更を行いません。 


(警告） 

LIB . X が見つかりません。 

ライブラリの形式は . a 形式のままです。 
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正しく “LIB . X ” が見つかった場合，インストールプログラムはすべてのライブ 
ラリを“.1”形式に変換します。 


ライブラリの形式を.1形式に変換します。 

変換 libc.a — > libc.l 
変換 libdos.a — > libdos.l 

中略 

変換 libw.a — > libw . 1 
変換は無事終了しました。 


♦ ライブラリ名の選択 


の標準構成ではライブラリの名称 
が “ libc . a ” というように， ZC •とは前後 


が逆になっています 4 )。 GCC コンパイラと UBC ライブラ 、)という組み合わせ 


だけで使用するならばこのままでかまいませんが， XC コ ンパイラと LIBC ライブ 


ラリの組み合わせで使用したり， XC 環境と併用したい場合は名称を 1 C 形式に直 


さなければなりません。 


4) 詳しくは「ライブラリファ 
イルの使い方 j ( P .37) 
を読んでください。 


(質問) 

ライブラリの名称を XC 形式に変更しますか？ 

" clib . a " という XC 形式のライブラリ名を使用するなら" y " を 
" libc . a " という LIBC 形式のライブラリ名を使用するなら" n " を 
選択してください。 

中断するには CTRL + C を押してください。 


(回答）-> 


もし形式に修正したければ上記の質問に“ y ” で，標準構成のままでよけれ 
ば“ n ” で答えてください。なお，ライブラリの形式を“ .1” に変更すると選択し 
た場合，これ以降の画面の表示は “. a ” ではなく，“.1”になります。文中の表示 
例を，適宣読み変えてください。なお， バージョン 了ップなヒで Project LIBC 
Group がを再配布する場合は，つねに“ . a ” 形式で行いますから，なるベ 
くならば “. a ” 形式のまま使用するようにしてください。 
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(回答）-一> y 

ライブラリの名称を xc 形式に変更します。 

変更 libc.a -- > clib.a 
変更 libdos.a -- > doslib.a 

中略 

変更 libw.a ―> wlib.a 
変更は無事終了しました。 


ここまででライブラリパッケージのイン 
ストールは終わりました。後はあなたの 
“ AUTOEXEC . BAT ” を書き換えて，份7が正しく動作するように，環境を設定す 
るだけです。環境設定は自動または手動で行うことができます。 


♦ AUTOEXEC . BAT の書き換え 


(質問) 

最後にここまでのインストール結果に合わせて環境設定を行います。 
環境変数の設定 （ AUTOEXEC . BAT の害き換え）を自動で行いますか？ 
自動で行いたい場合は" y " を 
自分で行いたい場合は" n " を 
選択してください。 . 

中断するには CTRL + C を押してください。 

(回答）> 


5) 後は必要に応じて，エディ 
夕などで編集して使用し 
てください。もちろん編 
集しなくても使えます。 


もしあなたがコマンドシヱルとして “ C 0 MMAND . X ” を使用していて，自分の 
“ AUTOEXEC . BAT ” を「自動」で書き換えてほしいときには，上記の質問に“ y ” と 
答えてください。次に“ AUTOEXEC . BAT ” のあるドライブを聞いてきますから，そ 
の質問にも答えてください。ドライブ名には“:”をつけてもつけなくてもかまい 
ません。 

これで，必要な設定があなたの“ AUTOEXEC . BAT ” の「最後」に自動的に追加さ 
れます 5 )。次の画面表示例ではパッケージを “ A :\ usr \ lang ” にインストールし, 
ライブラリの形式に“.1”を，またライブラリの名称は変更しなかった場合を想 
定しています。 
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(回答）-一> y 

AUTOEXEC.BAT を自動的に編集します。 

(質問) 

AUTOEXEC.BAT はどのドライブにありますか？ 

ドライブ名を，たとえば A : というように答えてください。 

(回答）> A: 

AUTOEXEC.BAT の最後に以下の行を追加します。 

set mclude=A : \usr\lang\include 
set 丄 ib=A:\usr\lang\lib 
set GCC_LIB = • 1 
set GCC_NO_XCLIB=yes 

インストールはこれですベて終わりです。 
おつかれさまでした。 

C:\> 


反対に，勝手に“ AUTOEXEC . BAT ” を書き換えられては困るという場合やコマン 
ドシェルとして “ COMMAND . X ”以外のプログラムを使っている人は，環境設定を手 
動で行ってください。手動で環境設定を行う場合，必要な環境設定が画面上に表 
示されます。この環境設定をメモし，後はエディタなどを使い，自分の好みの環 
境にしてください。 

表示される形式は “ C 0 MMAND . X ” に対するものなので，もしコマンドシェル 
に ksh . x や fish . x などのプログラムを使用している場合はそのままでは使えま 
せん。適切な形に直してから編集してください。 


(回答）> n 

環境設定は手動で行ってください。 

具体的には AUTOEXEC.BAT に次の行を追加するか， 
あるいはすでにある行を変更してください。 


set include=A:\usr\lang\inc 丄 ude 
set lib=A : \usr\lang\liD 
set GCC_LIB=.1 
set GCC_NO_XCLIB=yes 

インストールはこれですベて終わりです。 

おつかれさまでした。 


C:\> 
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♦> ソースコー ドパッケージのインスト ー ル 


本セクシヨンではインストールプログラムのメッセージにしたがって ， LIBC 
のソースコー ド パッケージを イ ンストールする 手順に ついて 説明します。 


♦ 環境のチェック 


「環境の準備」 （ P .3) でも述べましたが， 
ソースコー ドパッケージを正しくインス 
トールするためには，ファイル名を21文字まで正しく認識させるよう，あらか 
じめ環境を設定しなくてはなりません。 

Human 68 k はファイル名を21文字まで扱えるにも関わらず，標準設定では 
そのうち先頭の8文字までしか認識しません。そのため，9文字目以降が異なっ 
ていても先頭さえ同じなら，別のファイルを同じファイルだと認識してしまいま 
す。 ソースコー ド パッケージ 中のファイルは非常に長いファイル名が多いので， 
このままではいくつかのファイルの名前が重複してしまいます。 

もしあなたが Human 68 k ver .2， ver .3 を使っているならば， “TwentyOne • X ” 
というフリーウェアを利用することで，この問題を解決することができます。し 
かし， Human 68 k ver . l を使っている場合，現段階では残念ながらあきらめざ 
るを得ません。いくつかのフアイルが失われることを覚悟してください。 


ファイル名を21文字すベて認識させること 


まず，インスト ー ルプログラムはあなたの Human 68 k の バージ ョンをチェ ッ 
クし，それに応じていくつかの質問をしてきます。 


Human 68 k ver .2 あるいは ver .3 を使っ 
ている場合，インストールプログラムは 
あなたが “TwentyOne • X ” をすでに使っているかどうかを調べ，もし使用してい 
なければ次のようなメッセージを表示してきます。 


♦ Human 68 k ver .2 / ver .3 


(質問） 

あなたは TwentyOne . X を常駐させていないようです。 
ソースコード パッケージを正しく インス トー ルするには 
このプログラムを常駐させておかなければなりません。 

TwentyOne . X をどのデイレクトリにコピーしますか。 
デイレクトリ名で答えてください。 


中断するには CTRL + C を押してください。 


(回答) 


-> 
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“ TwentyOne . X ” をインストールするディレクトリを指定してください。たとえ 
ば“ A : \ nsr \ bin ” にコピーしたければ，次のようにタイプします。 


(回答)-> A :\ usr\bin 


ディレクトリを指定すると，インストールプログラムはそこに “ TwentyOne . X ” 
をコピーし，次のようなメッセージを表示して処理を中断します。そのメッセー 
ジにしたがって自分で “ CONFIG . SYS ” か “ AUTOEXEC . BAT ” を書き換え， X 68000 
を再起動（リセット）してください。 


(回答)-> A :\ usr\bin 

あなたの CONFIG . SYS に次の1行を書き加えてから 
リセットボタンを押してください。 

そして X 68000/ X 68030が正しく起動したら 
もう一度最初からインストールを行ってください0 

DEVICE = A :\ usr \ bin \ TwentyOne.X +TS 

あるいは，あなたの AUTOEXEC . BAT に次の1行を書き加えてから 
リセットボタンを押してください。 

そして X 68000/ X 68030が正しく起動したら 
もう一度最初からインストールを行ってください。 

A : \ usr \ bin \ TwentyOne -X +TS 

C :\> 


Human 68 kver . l を使っている場合，イ 
ンス トールプログラムはファイルが失わ 

れる可能性があることを警告します。 


♦ Human 68 k ver.l 


(警告) 

HUMAN ver . l では今のところ，ファイル名を21文字すベて 
認識させることができません。 

結果として，いくつかのファイルが失われることになります。 
あらかじめ了解しておいてください。 
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ソースコードをインストールするデイレ 
クトリを指定してください。インストー 
ルプログラムは，指定されたデイレクトリにすベてのデータをインストールでき 
るかどうか，空き容量をチェックし，十分な空きがあればインストールを開始し 
ます。 


♦インストール先の指定 


(質問) 

それでは「ソースコードパッケージ」をインストールします0 
どこにインストールしますか？ 

ディレクトリ名で答えてください。 

中断するには CTRL + C を押してください。 

(回答） 一 > 


たとえば “ A :，， ドライブの “\ usr \ lang ” というディレクトリにインストールし 
たいときは，次のようにタイブしてください。なお，ライブラリパッケージと 
ソースコードパッケージは別々のディレクトリにインストールすることもできま 
す。しかし，もし可能であれば，できるだけ同じディレクトリにインストールす 
るようにしてください。 


(回答）- > A :\ usr\lang 


ここで，もしディスクの空き容量が足りない場合は次のようなメッセージが表 
示され，インストールプログラムは中断します。インストールするディレクトリ 
をもう一度確かめてから，インストールを最初からやり直してください。 


(警告） 

指定したディレクトリには「ソースコードパッケージ」を 
インストールするだけの空き容量がありません。 


ディスクの空き容量の確認が終わると，インストールプログラムはパッケージ 
のインストールを開始します。場合にもよりますが，すべてを展開するにはおよ 
そ10分から15分かかります。 

ソースコー ドパッケージのインストールはこれで終了です0「ライブラリノ、。ッ 
ケージ」もいっしょにインストールすると指定した場合は，この次にライブラリ 
パッケージのインストールが開始されます。前節の「ライブラリパッケージのイ 
ンストール」 （ P .5) へ戻ってください。 
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それでは「ソースコード パッケージ」 をインストールします。 
src / 

src/DefaultBases 
src/DefaultRules 
src/Makefile 

中略 

README 

WARNING 

インストールは無事終了しました。 

おつかれさまでした。 

C :\> 
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❖ について 


を使い始める前に， L 7 BC の生い立ちについて説明しておきます。まず， 
ZJ 5 C は決して機能や性能という側面からではなく，あくまでもフリー（自由）な 
開発環境を提供するために，作成されたものだということを認識しておいてくだ 
さい。 


1) 著作権の制限を受けない 
という意味でフリーな。 


♦ L / 万 C •の意味 


LIBC の怍成は X 68000 の Human 68 k 

上で使うことのできる，まったくフリー 


(自由）な 1 )ライブラリという位置付けで，1991年に開始しました。確かには 


ソースコードが最初から付属していましたし，使用にあたってもほとんど制限は 
ありません。そういう意味では，はバグが多かったとはいえ，素晴らしいも 
のには違いありませんでした。 

しかし Human 68 k 上の開発環境は，すでにその当時， ZC が発売されたころ 


とはすっかり様子が変わっていました。 GCC(GNU C Compiler ) によって C 
コンパイラが，また HAS ( High-speed Assembler ), HLK ( High-speed Linker ), 
HAR ( Hi g h - s P eed Archiver ) によってアセンブラ，リンカ，アーカイバが，そし 
て GDB (GNU Debugger ) によって ソースコード デバッガまでがフリーウェアと 
して手に入るようになっていたのです。そのような状況下で，最後までフリーで 
はなかったのはライブラリだけで，逆にいえばライブラリがフリーになるのは， 
ある意味では必要なことでした。 


2) 月額料金で開くことがで 
き，趣向の同じ人どうし 
が集まることのできる小 
さな会議室。 


開発の開始と中止 


LIBCH , 最初はいろいろな人に好きな 
関数を作ってもらい，それをまとめる形 
で完成させる予定でした。実際，商用 BBS である Nifty - Serve 内に ホーム パー 
ティー 2 )を設置し，そこで開発していましたが，それは次のような問題によって 
中止せざるを得ませんでした。 


1. 重複 

まず，各人から好きな関数を寄せ集めても，その大半が重複してしまうこと 
が問題でした。それも，特に一部の関数に集中して重複してしまったのです。 
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そういった重複した関数ばかりが集まる一方で，それ以外の，本当に重要な 
部分は何もできあがりそうにありませんでした。 

2. 混乱 

ライブラリはさまざまな規格によって仕様がきちんと定まっています。しか 
し，どのような規格をベースとして採用するかは，依然として流動的でした 
し，規格に正しく合致しているかを調べるのは大仕事でした。また，ライブ 
ラリ内の関数は他のいろいろな関数と密接に結びついているため，それらの 
間のインタフェイスを取らねばならないことも難問でした。 

3. 障害 

もともとが有志による活動だったせいもありますが，ライブラリ自体の作成 
は遅々として進みませんでした。また著者自身の仕事などの都合もあり，言 
いだしっぺ本人が作成作業を中断してしまいました。 

結局のところ，自由気ままにやっていてできるようなものではないという現実 
だけがわかりました。こうしてライブラリの作成という企画は，棚にあがったま 
ま4か月近くも放置されるはめになったのです。もしそのまま何もなければ，永 
久に消え去っていたかもしれません。 


この企画が再度もちあがったのは，実は 

♦ pi 発の再開 

_ソフトバンクのおかげでした。1992年の 

3月に，ライブラリを題材にして本を出してみようという話になったのです。今 
このライブラリがあるのは，すべてこのときの担当者の方々の決断によるといっ 
ても過言ではないかもしれません。 

再開されたこの企画は L / fiC と名付けられました。これは UNIX 上で C 言語 
の標準ライブラリである“ libc . a ” の名前から取ったものです。普通， libc とい 
えば標準ライブラリのことを指しますが，本書ではこのような経緯から ， LIBC 
をライブラリ全体 3 )の総称として使っています。 


❖ LIBC は PDS である 


LIBCU フ リー（自由）な開発環境を支援するために， PDS として公開されてい 
ます。次に述べる事柄をよく理解し，その趣旨を理解していただければ Project 
LIBC Group としてもうれしいかぎりです 0 

PDS とは Public Domain Software の略 
語で，簡単にいえば「著作権が放棄され 
たもの。みんなのもの （_PuWic Domain )」 的な意味あいをもっています。著者は 
法律には詳しくないので，あまり詳しいことはいえませんが，たとえばアメリカ 
では著作物に明確に“ Copyright ” と記さないと蕃作権が発生しないそうです。そ 


♦ PDS とは 


3) つまり，標準間数ではな 
いものも含めてすべて。 
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4) しかしなかには筆者のよ 
うに， PDS にこだわる 
人間もいます。 


こで PDS では，故意にこの“ Copyright” を書かないことで著作権を放棄し，誰 
にでも自由に使ってもらおうというわけです。 

一方，これに対してフリーウェアやシェアウェアというものがあります。フリー 
ウヱアとは誰にでも使ってもらおうという点では PDS と同じですが，著作権は 
明確に宣言されており，ソフトウヱア作者の意志でどこまで自由に扱えるかも異 
なっています。また，シェアウェアはフリーウェアと似ていますが，気にいった 
らお金を送ってほしいというただし書きがつきます。 

以前，おそらく著者の思うところでは5, 6年以上前では PDS というのはわり 
と一般的に存在していたと思うのですが，最近はすっかり見かけなくなりました。 
今は，特に日本では，ほとんどすべてがフリーウェアかシェアウェアという形態 
をとっているようです 4 )。というのも，どうやら日本での著作権の扱い方があち 
らとは異なっているからのようでした。 

日本ではアメリカとは異なり，特に明示的に“ Copyright” と書かなくても自動 
的に著作権が発生するそうです。しかも，本人が希望してもどうしても放棄でき 
ない 著作権があるということで，つまり正確にいえば，日本では PDS という形 
態そのものが成立しないのだそうです。 


5) これは作者の意志によつ 
て制限が加えられる場合 
があります。 


6) こういうことが無条件に 
認められている場合もあ 
りますが，一般にはちゃ 
んと了解を得るのが礼儀 
です0 


フリーウェアやシヱアウェアは誰でも自 
由に使えるの側面をもっていますが，や 
はり著作権によって保護されており，使用に制限が課せられています。 

著作権者の立場で考えればこれは当然のことであり，著作権は厳格に守られね 
ばなりません。しかし逆に使う側の立場からすれば，たとえ「誰でも自由に使っ 
てください」とはいえ，「使わせてもらう」立場には違いありません。また，その 
ソフトウヱア中の一部を参考にしたり，流用したりするには著作権者の了解が必 
要です 6 )。これでは自由なソフトウヱアを開発するのに，少なからず障害になる 
のではと筆者は考えました。そこで，使う側の人が何の気兼ねもなく自由にソー 
スコードを利用したり，参考にしたりできるように LIBC を PDS として公開す 
ることにしたのです。 


♦ なぜは PDS か 


以上のことを踏まえ，我々は•のラ 
イブラリ，オブジェクト，インクルード 
ファイルからそのソースコードにいたるまで，そのすべてを PDS として公開し 
ます。誰でも自由に LffiC を使えるし，コピーすることも，改変することも，ま 
た自分のソフトウェアに組み込むことさえできます 。 Project LIBC Group には 
ソースコードを書く人も，テストする人も，そして保守する人もいますが，それ 
は単にそれだけの存在であり，著作権者という立場ではありません。 

我々はに関するすべての著作権を放棄します。また放棄できない部分に 
ついても， LffiC が意味的に PDS として成立するよう，著作権を主張しないこと 
を宣言します。我々が知識の自由な共有のためにできることはこのくらいしかあ 
りませんが，•がすべての人の共有財産として，何かの役に立てばと考えて 
います。 


♦ は PDS である 
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ただ，以下のことには注意してください（いささか矛盾ですが • • 

LIBC は PDS ですが，本書は PDS ではありません 
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♦ コントリビューシヨン 


LIBC への コ ントリビュー シヨ ン 7) はいつ 

でも歓迎します。著作権を放棄し，前述 
したような L / BC のポリシーにしたがっていただけるなら，あなたが作成した関 
数を我々に提供してください。我々は，それら コン トリ ビューション していただ 
いた ソースコードを， 将来の バージョンで に統合，配布したいと思ってい 
ます。 


7) コン トリビュー シヨンと 
(4 「寄付」と訳します。 

に対してプ a グラ 
ムゃデータを 無價で提供 
する」という意味でとら 
えてください。 


Project LIBC Gr ⑽ p は，できる範囲内 
で LIBC のバグ'7イクス， 機能拡張，追 
加などのバージョンアップ作業を随時行っていきたいと思っています。方法とし 
ては，全体の配布，差し替えファイルの提供，ソースコードのテキスト差分，バイ 
ナリ差分などがあります。これらのバージョンアップは， NIFTY - Serve の SHARP 
USER ， S フォーラム • ワークステーション館 （ FSHARP 3) にて行う予定です。もし， 
L / BC に対する要望や問い合わせ，バグに関する情報があれば，次に示す著者の 
ID に電子メールを送ってください。 

NIFTY-Serve … PGA 01555 ( PGA 01555@ niftyserve . or . jp ) 


♦ バージ ョ ンアップ 


ただし，これらのバージョンアップ作業は Project LIBC Group が独自に行 
うものであり，本書の発行元であるソフトバンクとは無関係です。また， X68k 
Programming Series #1 Develop. の著者グループと共同で出版する予定の追補 
版 8 )を除けば，シリーズの一冊として，書籍でバージョンアップ版を提供するこ 
とはありません。 

バージョンアップはパソコン通信以外では行いません 


8) 追補版では X 68030 へ 
のより細かい対応と，バグ 
フィクスを行う予定です0 


LIBCt XC 


最初に LIBC と ZC との関係と，そのなかでの LIBC の位置付けについてはっ 
きりさせておきます。つまり，だけでできることと，ではできないこ 
とがあるのです。 L 7 BC と XC のそれぞれの特長を考えて利用することが重要にな 
ります。 


は JTC 7 に置き換わるものではあり 

♦ ZJ 及 (7 は ZC に置き換わるか 

_ ません0確かに，当初はをと 

並ぶものとして，つまり XC •を完全に置き換えるつもりで作成していました。し 
かし結論からいえば，お C にも ATC •にもそれぞれに得手不得手があり， LIBC さ 
えあれば後は何もいらないとは一概にはいえません。 
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9)LIBC は ，X BASIC につ 
いては一切サポートし 
ていません。 


ただ念のために記述しますが， L / 只 C は XC に対して上位コンパチブルになるよ 
うに設計されています。ですから一部の互換性のない関数を除けば 9 ), XC ででき 
ることはでもできます。 

それでは両者の得手不得手を1つずつ見ていくことにしましょう。最初に断 
わっておきますが，これは筆者の主観的な意見です。ですから，使う人にとって 
は長所もまた短所になりうるし，その逆もありえるでしょう。どちらでもよいと 
思う人もいるかもしれません。しかし1つの判断基準にはなるのではないかと思 
います。 


〇 份7の長所 


10) 詳細については前述した 
「 PDS とは」 （ P .15) を 
参照してください。 


11) 詳細については後述する 
1 ■インクルードファイルの 
互換性 j ( P .21) を参照 
してください。 


1. ソースコー ドがすべて公開されている 

ももちろんソースコードが公開されていますが， L 招 C のソースコー 
ドは著作権を主張しない PDS として公開されています。また，ソース 
コードの95%は C 言語で書かれており， コメント も十分に書き込まれて 
いるために理解がしやすくメンテナンスも楽でしょう。 

2. ライブラリすべてが PDS である 

ZJ 及 C は商品でもなければフリーウェアでもありません 10 )。 PDS として 
著作権とは無縁のものです。したがって，誰でもどんな用途にでも自由 
に使うことができ，また自由に改変/コピーができます。 

3. 他の処理系との互換性が高い 

LIBCit , 当初から UNIX からの移植をしやすくするという目的があ 
りましたから， UNIX にしかないような関数， インクルードファイル， 
システムコールを 多く含んで います。 また同時に， MS—DOS との ソー 
ス互換性を高める意味でも， MS-C 7. 0などの機能を採り入れています。 

4. さまざまな規格に対応している 

LIBC は ANSI C の標準ライブラリの仕様を満足しているだけではなく， 
可能なかぎり，たとえば POSiU や UiRSZ ) や SKSF の仕様 
(規格ではありませんが）など，さまざまな機能を取り込んで設計されて 
います 11 )。 

5. ある程度有用なシグナル機構 

XC ではほとんど意味をなしていなかったシダナル機構を，同ープロセ 
ス内にかぎってですが，有効に動作させるようにしてあります。これは 
同時に， UNIX からの移植性を高めることにも役立っています。 

6. バソコン通信で継続的なサポートがある 

もしライブラリに不都合やバグがあれば，バソコン通信上でそれを随 
時修正していく予定です。また，機能の拡張や関数の追加も行われるで 
しょう。詳しくは前述した「バージョンアップ」 （ P .17) を参照してくだ 
さい0 
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Chapter 1 一 LIBC リファレンス 

0 ZJ 忍 C の短所 

1. 実行ファイルが大きくなる 

LIBC は 95% が C 言語で書かれていること，機能が豊富なこともあって， 

ライブラリ自体の大きさが XC の 1.5 〜2倍近くあります。特に小さい 
プログラムをコンパイルすると，できあがる実行ファイルの大きさの違 
いは顕著に現れます。たとえば List 1-1 のような短いプログラムを例に 
すると， ZC では 10K バイトちょっとの実行ファイルが，では 20K 
バイト近くになることもあります。機能とサイズでのトレードオフが必 
要でしょう。 


List !-!• とても短いプログラム 


1 ： /* 

2 : ** hello.c: 

3: ** 世界で 1 番有名なプログラム。画面上に "Hello world !!" と表示 

4: する 

5: */ 

6: #include <stdio.h> 

7: 

8 : 11 it mam kvoid) 

9: { 

10: printf ("Hello world !!\n"); 

11: return 0; 

12: } 


2. 実行速度がやや遅い 

LIBC は考えられるかぎり高速になるように設計してはいますが， ZC と 
比較した場合，がオールアセンブラであり，機能的にも限定されて 
いる点を考慮すると「遅く」はありませんが，「やや遅い」とはいえるで 
しょう。使う関数にもよるので，一概にどれだけ遅いかは判定できませ 
ん。場合によっては速くなる場合もあります。ですから，実際に使用し 
てみることをお勧めします。 

3. 商品ではない 

が商品ではなぐ PDS として公開されていることは長所でもあり， 
逆に短所でもあります。は商品ではないために，悪くいえば「信 
用できない」し，サポートも「期待できない」ことになります。先ほど 
サポートは「する予定」と書いたものの，「期侍できない」のもまた事実 
です。もっとも X 68000 ユーザならば，自分でイ可とでもしてしまう方が 
多いかもしれませんね。 

4. I - 凡 457 C •をサポートしていない 

LIBCH XC のように I - 及 4 S 7 C をサポートしていません。“ベーシック 
— C コンバータ”もありませんし，ベーシックライブラリ （“ baslib . a ”） 
やそのためのインクルードファイルも備えていません。ですから，スプ 
ライトや PCM ， FM 音源関数を使ってのプログラミングはできません。 
ただし， IOCS コールライブラリはありますから，どうしても必要なら 
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ライブラリー第 1 部 


I 2 )これは L / 丑 C を作成する 
うえで最低限必要な選択 
でした。 


ば直接 IOCS コールを使ってプログラミングしたり， I/O を操作するこ 
とは可能です。 

5. 数値演算コプロセッサがない場合は FLOAT パッケージに依存する 

は数値演算コプロセッサが装備されていると，自動的にそれを使っ 
て数学関数の演算を行います。しかしコプロセッサがない場合は，必ず 
FLOAT パッケージを必要とします。 XC のように，ライブラリ内部に計算 
ルーチンをもたせることはできません。 

6. XC 上で開発されたライブラリと互換性がない 

ZJBC はソース レベルの 互換性だけを考慮し，オブジヱクトレべ ル，つ 
まり “. a ” ファイル や“.1” ファイルレベルの 互換性は無視しました 12 し 
ですから，これまで力：の標準ライブラリとリンクすることを想定して 
作られたライブラリは，そのままではリンクできません。一度再コンパ 
イルする必要があります。また，逆にのライブラリを ZC にもって 
いくこともできません。なぜならば，内部構造が異なっているからです。 


以上で，にはさまざまな長所と短 
所のあることが理解できたかと思います。 
ですから，このの長所および短所を理解したうえで， XC なりなりど 
ちらでも好きなほうを使えばよいのです。 

たとえば，あなたが FM 音源やスプライトを用いたゲームを作ろうと思ってい 
るならばを使うべきです。 ZC にはスプライトや FM 音源， PCM を比較的簡 
単に扱える関数がたくさんあります。それらを使えば，を使うよりもより 
簡単にプログラムを作成できるでしょう。それに，おそらく ZC のほうが速いと 
思います。 

しかし，あなたが今 UNIX や MS—DOS 上のプログラムを移植しようとした 
り， AiVSJC 1 に準拠した正しいプログラミングを学ぼうというのであれば ， LIBC 
を選択するほうがよいかも知れません。 LffiC は义 iVSJ C の標準ライブラリに忠 
実ですし，もともと UNIX からの移植を行うために作られています。速度や実 
行フアイルのサイズに多少の犠牲は出ますが，それはやむを得ないと割り切って 
ください。 


♦ との選択 
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Chapter l—LIBC リファレンス 


1.3. インクルードファイルの使い方 


❖インクルードフアイルの互換性 


は次の資料を基に開発されました。本書では，文中でそれぞれの資料 
を引用するために POSIX.l, XPG3, AES/OS 、 SYSV ， 4.3BSD, 

MS - (7 7.0という表記を用いています。 

〇 ANSI C 

米国規格協会 （ANSI - American National Standards Institute ) の X 3 J 11 
委員会で1989年 12 月 14 日に承認，制定された C 言語の標準化案 。 ANSI 
X 3.159-1989, Programming Language C. 

O P0SIX.1 

米国電気電子学会 (IEEE - the Institute of Electrical and Electronics En¬ 
gineers, Inc.) が制定したオペレーティングシステムに関する標準化案。 
POSIX (IEEE Std 1003.1-1988, Portable Operating System Interface for 
Computer Environments.) および IEEE Std 1003.1 -1990， Information 
Technology-Portable Operating System Interface (POSIX)-Part 1 : Sys¬ 
tem Application Program Interface (API) [C Language ]. 

〇 XPG3 

X/Open Company Limited . が作成したコンピュータ環境に関する標準化案。 
X /Open Portability Guide Issue 3, Volume 2-1989 XSI System Interface 
and Headers. 

〇 AES/OS 

OSF (Open Software Foundation ) が作成したオペレーテイングシスアムに 
関する標準化案 。 Application Environment Specification ( AES ) Operating 
System Programming Interfaces Volume , Revision A. 

O SYSV 

米国電信電話会社 ( AT&T - American Telephone and Telegraph Company ) 
が作成した UNIX System V に関する次の資料 0 SVID Issue1 - System V 
Interface Definition, Issue 1 ,Spring 1985 および SVID Issue 2 - System 
V Interface Definition Issue 2,1986 および SVID89 - System V Interface 
Definition, Issue 3, Industry Review Draft , December 21,1988. 
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〇 4.3 BSD 

米国カリフォルニァ大学バークレー校で作成された UNIX のバージョン 
4.3 BSD に関する次の資料 。 UNIX Programmer's Reference Manual , 4.3 
Berkeley Software Distribution ( BSD ), April , 1986. 

O MS - C 7.0 

米国マイクロソフト社 (Microsoft Corporation ) が販売している C / C ++ コ 
ンパイラ ， Microsoft C / C ++ のマニュアル 。 Microsoft C / C ++ Run-Time 
Library Reference Covers version J . 


❖インクルードファイルー覧 


1/万(7のインクルードファイルは AAW / C ， XC , MS - C 7.0, P 0 SIX .1， XPG 3, 
A 私 S / OS などの規格で定義されているインクルードファイルに加え， 4.3 BSD や 
STST がもっているインクルードファイルにも対応しています。本セクシヨンで 
は，これらの数多くのインクルードファイルを9つのカテゴリに分類して，解説 
します。 


n は A / VS 7 C で規定されているイン 

♦ ん / V 57 C •インクルードファイル 

_クルー ドファイルをすべて備えており， 

それぞれ次のようなことがらを宣言あるいは定義しています。これらのファイル 
は，ほとんどすべての処理系（もちろん XC にも存在していますから）で使用す 
るのに制限はありません。ただし，処理系によっては 47 V 57 C への対応がやや異 
なっている場合があります。 


• assert.h 

プログラム診断を行うマクロの定義 

• ctype.h 

文字の分類を行う関数とマクロの宣言 

• errno.h 

変数 errno とその値を表現するマクロの宣言 

• float.h 

float 型， double 型 ， long double 型それぞれの浮動 

小数表現の表現範囲の定義 

• limits.h 

char 型， short 型， 10 ng 型それぞれの表現範囲を始 

めとして，いろいろな値の制限値の定義 

• locale.h 

ロケールについての定義。ただし，では C ロケー 

ルしか対応していないため，実質的には機能しない 

• math . h 

数学関数の宣言 

• setjmp.h 

大域ジャンプの定義 

• signal.h 

シグナル機構の定義 

• stdarg.h 

可変長引数を取り扱うマクロの定義 

• stddef.h 

ANSI C で使用される標準データ型とマクロの定義 

• stdio.h 

高水準ファイル入出力である stdio ライブラリの定義 
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• Stdlib.il ほかの分類に属さない，その他いろいろの関数の宣言 

• string.h 文字列を扱う関数の宣言 

• time.li 時間を扱う関数の宣言 


ZC インクルードファイル 


LIBC は との ソースレベルの 互換性 
を考慮して設計しており，が備えて 
いるインクルードファイルのうち，ム泌<7で代用可能なものについては互換ファ 
イルがあります。これらの互換ファイルは関数名の置き換えを行っているものも 
あれば，同じ働きをする別のファイルを読み込むだけのものもあります。最低限 
の互換性は保証していますが，完全に同じとはかぎりません。あらかじめ了解し 
ておいてください。 


• conio.h 

• doslib.h 

• io.h 

•locslib.h 

• jctype.n 

• jstring.h 

• process.h 

• sys/timeb.h 


コンソール直接入出力を扱う関数の宣言 

DOS コールを扱う関数を宣言しているが， LIBC では 

代わりにく sys / dos . h > を用いるのが普通 

低水準入出力を扱う関数を宣言しているが ， LIBCXH 

代わりに < unistd . h > を用いるのが普通 

IOCS コールを扱う関数を宣言しているが， LIBC では 

代わりにく sys / iocs . li > を用いるのが普通 

シフト JIS コードの日本語文字を分類する関数とマクロ 

を定義しているが， LIBC では代わり に <mbctype . h > を 

用いるのが普通 

シフト JIS コードの日本語文字列を扱う関数を宣言し 
ているが， LTSC では代わりに Cmbstring 上〉を用いる 
のが普通 

子プロセスを呼び出す関数を宣言しているが， LIBC で 
は代わりにく皿 istd . h 〉 を用いるのが普通 
現在時刻を得る関数の宣言 


LWC は MS-C 7.0 で作成された ソース 
ファイルを，なるべく少ない変更で動作 
させることができるように設計されており， MS - C 7.0 が備えているイ ンクルー 
ドファイルのうち， L / fiC で代用可能なものについては互換ファイルがあります。 
しかし，この MS - C 7.0 との互換性はおもに関数 レベルで 行っており，これまで 
紹介してきたイ ン クルードファイル中にすでに含まれていますから，イ ン クルー 
ドファイル自体は多くありません。 

• mbctype . h シフト JIS コード体系の日本語文字を分類する関数と 

マクロの宣言。 J / S - C 反0以前のバージョンとの互換を 
保つにはく jctype . h 〉 を用いる 

• mbstring.h シフト JIS コード体系の日本語文字列を扱う関数の宣 

言。以前のバージョンとの互換を保つには 
<j string • li > を用いる 


♦ 7.0 インクルードファイル 
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• sys / locking.h ファイルロックを行う関数の宣言 


PaSTX .7 インクルードファイル 


LIB(m POSIX .1 をベースにして作成し 
ており， postx . j で規定されているイン 
クルードファイルをほとんど備えています。ですから，尸 OS 7 X .2 に対応して作 
成されたソースファイルとの互換性はある程度保たれています。ただし，インク 
ルードファイル中には将来実現されることを見込んで作成したものもあり，実際 
には何ら機能しないものもいくつか存在します。また，これらのファイル中では， 
規格チヱックのための _ P 0 SIX _ S 0 URCE マクロをチェックしていません。 


• dirent.h 

• fcntl.h 

• grp.h 

• pwd.h 

• sys/stat.h 

• sys/times.h 

• sys/types.h 

• sys/utsname.h 

• sys/wait.h 

• termios.h 


ディレクトリエントリを検索する関数の宣言 
ファイルのオープンやファイルハンドルの操作を行う 
関数の宣言 

グループファイルを扱う関数の宣言 
パスワードファイルを扱う関数の宣言 
ファイルの情報を取得する関数の宣言 
現在は機能しない 

POS 7 X .2 で使用するデータ型と マクロの 定義 
システムに関する情報を取得する関数の宣言 
現在は機能しない 
現在は機能しない 


• unistd.h 低水準入出力など UNIX システムコールに関する宣言 


♦ インクルードファイル 


LIBC は XPG 3 についてもある程度対応 
して作成しており， ZPG 5 で規定されて 


いるインクルードファイルを備えています。ですから，エ戶以に対応して作成さ 
れたソースファイルとの互換性はある程度保たれています。ただし，これらのイ 
ンクルードファイルは将来実現されることを見込んで作成したものであり，実際 
には何ら機能しないものがほとんどです。また，これらのファイル中では，規格 
チェックのための」 COPEN - SOURCE マクロをチヱックしていません。 


• ftw.h 

• langinf 〇 .h 

• nl_types .h 

• regexp.h 

• search.h 

• ulimit.h 

• varargs.li 


現在機能しない 
現在機能しない 
現在機能しない 
現在機能しない 
現在機能しない 
現在機能しない 

可変長引数を取り扱う古いスタイルのマクロの定義 
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♦ AES/OS と SVR 4 


ZJ 5 C は AES / OS や SVR 4 についてもあ 


る程度対応して作成しており， AES/OS 


で規定されているインクルードファイルを備えています。ですから， AES / OS ^ 
5^/24に対応して作成されたソースファイルとの互換性は，多少なりとも保たれ 
ています。ただし，これらのインクルードファイルは将来実現されることを見込 
んで作成したものであり，実際には何ら機能しないものがほとんどです。また， 
これらのファイル中では，規格チェックのための _ AES_SOURCE マクロをチェックし 
ていません。 


• poll.h 

• sys / mman.h 

• sys / timers.h 

• wctype.h 

• widec.h 

• wstring.h 


現在機能しない 
現在機能しない 
現在機能しない 

幅広文字を分類する関数とマクロの定義 

幅広文字を stdio ライブラリで扱うための関数の宣言 

幅広文字列を扱う関数の宣言 


♦ その他の互換ファイル 


ではこれまでに紹介したイ ンクルー 
ドフアイル以外にも SYSV や 4.3 BSD の 


ソースコードとの互換性を考え，いくつかの互換ファイルを提供しています。た 
だし，これらの互換ファイルは関数レベルの互換性というよりは，インクルード 


ファイルの名前やディレクトリ中の位置が異なるのをカバーするためのものです。 


• alloca.h alloca 関数の宣言 

• malloc.h く stdlib 上> の別名 


• memory.h 

• strings.h 

• sys / air.h 

• sys / exec.h 

• sys / fcntl.h 

• sys / file.h 

• sys / param.h 


• sys / signal.h 

• sys / time.h 

• sys / resource.h 


〈 string . h > の別名 
< string . li > の別名 
く dirent . h > の別名 
< a_out . h 〉 の別名 
< fcntl . li > の別名 
く f cntl 上〉の別名 

〈 limits . h 〉 の別名であるとともに，このファイル特 
有の マクロを いくつか定義している 
〈signal . ti > の別名 
現在は機能しない 

システムリソースを 操作す る 関数の宣言 


最後に L /5 C 特有のインクルードファイ 
ルを説明しておきます。これらのファイ 
ルは L 仿¢7に特有のものなので，もし他の処理系，たとえば AX 1 ， MS - C 7.0, 
UNIX などへの移植を考えてプロダラミングするならば，決して使用しないで 
ください。 


♦ L / fiC インクルードファイル 
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• a _ out . h 

• interrupt.h 

• wchar . h . 

• sys / dos.h 

• sys / iocs.h 

• sys / project.h 

• sys / scsi.h 


X 型の実行ファイルと ZJ 5 C が生成する “ core ” ファイ 
ルの構造の定義 

GCC で割り込みを記述するために必要なマクロの定義 

幅広文字を扱うための宣言 

DOS コール ライブラリの宣言 

IOCS コール ライブラリの宣言 

LIBC のバージョ ンを求めるための関数の宣言 

SCSI コール ライブラリの宣言 


次に示したファイルは，を作成す 
るためのライブラリ内部のインクルード 
ファイルですから，普通は使用しないでください。これらのファイルには移植性 
がなぐしかも内容が将来変更される可能性があります。ライブラリの内部構造 
をよく理解している人や，ライブラリを作成する人のみ使用するようにしてくだ 
さい。 


♦ L 75 C の内部ファイル 


• cdec 丄 .Ji 

• sys / dos _ i.h 

• sys / aos_p .h 

• sys / iocs _ i.h 

• sys / iocs _ p.h 

• sys / xdoseml.h 

• sys / xglob.h 

• sys / xgrp.h 

• sys / xmath.h 

• sys / xmbstring.h 

• sys / xprof.h 

• sys / xpwd.h 

• sys / xresource.h 

• sys / xsignal.h 

• sys / xstart.h 

• sys / xstat.h 


すべてのインクルードファイルに読み込まれるファイル 

DOS コールをイ ンライン展開するための宣言 

DOS コールのプロトタイブの宣言 

IOCS コールをインライン展開するための宣言 

IOCS コールのプロトタイプの宣言 

DOS エミュレーシヨン関数のためのファイル 

ライブラリ用のグローバル関数のためのファイル 

グループファイル関数のためのファイル 

数学関数のためのファイル 

マルチバイト文字列関数のためのファイル 

プロファイラのためのファイル 

パスワードファイル関数のためのファイル 

リソース関数のためのファイル 

シグナル機構のためのファイル 

スタートアップ関数のためのファイル 

st at 関数のためのフアイル 


• sys / xstdio.h 

• sys / xstdlib.h 

• sys / xtime.h 

• sys / xunistd.h 


stdio ライブラリのためのファイル 
標準ライブラリのためのファイル 
時間関数のためのファイル 

UNIX システムコールエミュレーシヨンのためのファ 

イル 
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❖インクルードファイルの使い方 


のインクルードファイルは， GCC でもでも使用することができま 
す。本セクションではそれぞれのコンパイラで， L / J 5 C を利用する手順について 
説明します。 


基本的には，このは GCC で使用 
してください。 ZC •でも使用することは 
できますが，では十分なテストを行っていません。さらに XC では， L 1 BC の 
機能を十分に引き出すことは無理でしょう。 

GCC で ZJ 5 C を使うためには， L /5 C の include ディレクトリの位置を環境 
変数 include に設定する必要があります。たとえば， ZJJ 5 C をインストールする 
ときに，インストール先ディレクトリとして “ A : Visr \ lang ” を指定したならば， 
環境変数 include には “ A :\ usr \ lang \ include ” と設定してください。もちろん 
パス名の区切りとして，のほかに‘7” を使うこともできます。その場合は， 
“ A : / usr / lang / include ” となります。 

もしあなたがコマンドシェルとして COMMAND . X を使っているならば，自分の 
“ AUTOEXEC . BAT ” に次の1行を加えてください。 


♦ GCC で使う 


set inc 丄 ude=A : \usr\lang\inc 丄 ude 


XC で LffiC を使う方法は， GCC で 
LIBC を使う 場合と基本的には同じで 
す。しかし環境変数 include に設定するパス名の区切り記号は，必ず“を使用 
してください。“/”も使えるかも知れませんが，“\”のほうが無難です。そして 
同じように， “ AUTOEXEC . BAT ” に次の1行を加えてください。 


♦ で使う 


set inciude=A:\usr\lang\ 111 elude 


重ねて説明しますが， AT では L 仿 (7 のすベての機能を使用することができませ 
ん。できるだけ， GCC と組み合わせてお使いください。 


は GCC で使用してください 
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❖インクルードファイルについて 


LIBC のイ ンクルードファイルは表面的な仕様以外にも，たくさんの仕様が含 
まれています。この機能をより有効に利用するために，次の説明と注意点をよく 
読んでおいてください。 


1) X 68000 上ではこのよ 
うなコンパイラはありま 
せん。 


LIBC は ん /VS/C ベースで開発されるこ 
とを想定しており，古い/時代の C 
言語にしか対応していないコンパイラ 1 )での使用は想定していません。すべての 
関数は厳格にプロトタイプ宣言してあり，引数の型まちがいを適切に判断できる 
ようになっています。またポインタに対しては，必要に応じて const 型として宣 
言してありますから，不用意な領域書き換えも防げます。 

特に GCC といっしょに使用するときには， GCC の拡張機能である関数属 
性も正しく評価されるように工夫してあります。副作用のない関数には— const 
型の関数属性を，また呼出元に戻ってこない関数には -volatile 型の関数属性を 
宣言しています。 


♦ 関数のプロトタイプ 


2 )たとえば new や delete 
文を処理する内部間数 
など。 


3) これらはいずれもフリー 
ウェアとして公開されて 
います。 


L/5C は， C++ 言語で使用されることを 
最初から考慮してあります。 L7BC のイ 
ンク ルードファイルは— cpluscplus マクロが 定義されているかどうかによって， 
C 言語かそれとも C++ 言語かどうかを判断し， C++ 言語で使用される場合には 
ライブラリ関数のプロトタイプをすべて， extern "C" 〇 によって囲むように変 
イ匕します。 

このように，は C++ 言語で使用されることを想定してはいますが， C++ 
特有の関数 2 )については宣言していません。また，く stream.li> などのようなク 
ラスライブラリなどもありません。それらのライブラリは別途用意する必要が 
あります。たとえば， FSF (Free Software Foundatioji) の GNU プロジェクトで作 
成された “libg++” クラスライブラリや NIH (National Institute of Health) の 
“nihcl” クラスライブラリ 3 )などを移植して，利用されるとよいでしょう。 

LIBC では ，提供している関数のうちマ 
クロとして定義できるものについては関 
数版とマクロ版の両方を提供しており，用途に応じて使い分けられるようになっ 
ています。デフォルトではほぼす ベての ものについてマクロ版が使われるように 
設定されていますが，もし関数版を用いたい場合は，必要に応じて次の選択マク 
口を# define で定義してください。たとえばある関数のアドレスを得る必要が 
ある場合には，その関数は実体をもつ“関数版”でなければなりません。ただし， 
これらの選択マクロは，必ずインクルードファイルを読み込む前に定義してくだ 
さい。読み込んだ後に定義してもまったく意味をなしません。 


♦ 関数とマクロの切り替え 


♦ C++ 言語で使用するには 
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また，これと同様にインライン関数として定義したほうがよいものについても， 
関数版とインライン版の両方を提供しています0必要に応じて使い分けるとよい 
でしよう。 


• __NO_CTYPE_INLINE__ 


• __NO_SIGNAL_INLINE._ 

• __NO_STDIO_INLINE 一 - 


ロケール関数をマクロ展開しないようにする。 デ 
フォルトではマクロ展開 

文字を分類する関数をマクロ展開しないようにす 
る。デフォルトではマクロ展開。これを定義すると， 
く ctype.h 〉 で定義されている文字分類のほかに 
<mbctype.li> ， <jctype.h>, く wctype. ； h> も同 
様に影響される 

シグナル関数をマクロ展開しないようにする。デ 
フオルトではマクロ展開 

stdio ライブラリをマクロ展開しないようにする。 
デフォルトではマクロ展開 


• __NO_STDLIB_INLINE__ stdlib 標準ライブラリをマクロ展開しないように 

する。デフォルトではマクロ展開 

• __DOS_INLINE__ DOS コールをインライン展開する。デフォルトで 

はインライン展開はしない。ただし，インライン 
展開には非常に処理時間がかかる 

• __IOCS_INLINE__ 10 CS コールをインライン展開する。デフォルト 

ではインライン展開はしない。ただし，インライ 
ン展開には非常に処理時間がかかる 


たとえば次の List 1-2 を見てください。このプログラム中の文字分類を行う関 
数を，マクロ展開しないようにコンパイルするには，6行目のような記述が必要 
です。 



1 ： /* 

2 : ** lsupper . c : 

3: ** キーボードから文字列を入力してもらい，その文字列の 

4: ** 先頭が英大文字かどうかを調べる 

5: */ 

6: #define __NO_CTYPE_INLINE__ /* <— これが必要 */ 

7: 

8 : # include <stdio.h> 

9 : # include <ctype.h> 

10 : 

丄丄： 11 it main ^void) 

12 : { 

13: char buffer [256]; 

14: 

15: while (gets (buffer) != NULL) { 

16: if (isupper (*buffer)) 

17: printf ("YES!\n"); 

18 : else 

19: printf ("NO. An"); 

20 : > 
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21 : 

22 : return 0; 

23: > 


上記とは別の方法として，直接コンパイラに選択マクロを与えることでも同じ 
結果が得られます。次の画面の表示例では， GCC を使い，最適化ありでコンパ 
イルしています。 

A:\> gcc -□ -D__NO_CTYPE_INLINE__ isupper.c 
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❖ライブラリファイルー覧 


の 11のライブラリファイルを標準で提供しています。すべてのライ 
ブラリファイルは XC ver . l で使用されていた “. a ” 形式で提供されていますが， 
もしあなたがをもっているならば， LIB . X を用いて ZC ver .2 相当の“.1”形 
式にして使うと，より高速にリンクすることができます。 


• libc.a 
• libcplus.a 
• libdos.a 
• libiocs•a 
• libmb.a 
• libprof.a 
• libscsi.a 


C 言語の標準ライブラリおよびそれに類するもの 

C ++ 言語用の追加ライブラリ 

DOS コールライブラリ 

IOCS コールライブラリ 

日本語文字列処理ライブラリ 

GCC 用のプロファイルライブラリ 

SCSI コールライブラリ 


• libsigna 丄 .a 
• libsuper.a 
• libtz.a 
• libw.a 


シグナルライブラリ 

スーパーバイザモー ド実行用ライブラリ 
フル デコー ドタイム ゾーン ライブラリ 
幅広文字ライブラリ 


では，それぞれのライブラリに ついて， もう少し詳しく説明します。 


C 言語の標準ライブラリとそれに類する 
ものが含まれています。普通にブログラ 
ミングするだけならば，このライブラリだけで十分です。このライブラリは何も 
指定しなくても，コンパイラドライバ 1 )によって自動的にリンクされますから， 
GCC なり ZC のマニュアル通り，普通にコンパイルすれば大丈夫です。 

たとえば“ libc . c ” というプログラムがあるとします。このプログラムを GCC 
を使い，最適化ありでコンパイルするには次のようにタイプします。 


♦ libc.a 


A: \> gcc -0 11 bc.c 


1 )GCC なら gcc . x , XC 
なら cc . x のことを指し 
ます。 
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2) GNU プ a ジエクトが提 
供している C ++ コンパ 
イラ。 


♦libcplus.a 


C ++ 言語をサポートするライブラリで 
す。 C ++ 言語でプログラムする場合に 
は，必ずこのライブラリをリンクしてください。このライブラリをリンクしない 
と， LffiC は起動時と終了時にグローバルコンストラクタやグローバルデストラ 
クタの呼び出しを行いません。このライブラリは g ++ 2 ) を使うかぎり，何も指 


定しなくても自動的にリンクされます。 

実際にグローバルコンストラクタとグローバルデストラクタを使ったプログラ 
ムを見てみましよう。次の List 1-3 はグローバルコンストラクタ，クラスメソッ 
ド，デストラクタを使って文字列を表示するプログラムです。 


List 1-3 • C ++ のサンプルプログラム 


1： /* 

2 : ** cplus.c: 

3: C++ で Global Constructor/Destructor と Class Method を 

4： ** 使って文字列を表示する。正しく動作すれば "Beauty and the 

5: ** Beast " と表示される 

6 : */ 

7: #include く stdio.h 〉 

8 : 

9: class Sample { 

10 : public : 

11: Sample 〇 { printf ("Beauty"); } // Ctors 

12: ~Sample () { printf ("the Beast\n"); > // Dtors 

13: void and () { printf (" and "); > // Method 

14: >; 

15: 

16: Sample belle; // Class Sample のグローバルインスタンス 
17: 

18 : int main () 

19: { 

20: belle.and (); 

21 : return 0; 

22 : > 


このプログラムをコンパイルするには， GNU C ++ コンパイラである g ++ を 
用います。基本的な使い方は GCC と同じです。 List 1-3 を最適化ありでコンパ 
イルするには次のようにタイプしてください。 


A:\> g++ -0 cplus.c 
A:\> cplus.x 
Beauty and the Beast 
A:\> 
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DOS コール ライブラリが含まれていま 
す 。 DOS コールを使った プログラムを作 
成する場合は，このライブラリをリンクしてください。このライブラリは GCC ， 
ZC いずれの場合も自動的にはリンクされませんから，自分で明示的に指定する 
必要があります。 GCC ならば， “- ldos ” というオプションを指定してください。 

たとえば， DOS コールを使用する “ dos . c ” というプログラムがあるとします。 
これを GCC を使い，最適化ありでコンパイルするには次のようにタイプします。 


♦libdos.a 


A:\> gcc -0 dos.c -ldos 


IOCS コール ライブラリが含まれていま 
す。 IOCS コールを使った プログラムを 
作成する場合は，このライブラリをリンクしてください。ただし AX •とは異な 
り， SCSI 装置を扱うための SCSI コールが 別のライブラリになっています 。 SCSI 
コール ライブラリについては，後述する libscsi . a を参照してください。また, 
このライブラリは GCC , いずれの場合も自動的にはリンクされませんから， 

自分で明示的に指定する必要があります。 GCC ならば， “- liocs ” というオプ 
シヨンを指定してください。 

たとえば ， IOCS コールを 使用する “ iocs . c ” というプログラムがあるとしま 
す。これを GCC を使い，最適化ありでコンパイルするには次のようにタイプし 
ます。 


♦libiocs.a 


A: \> gcc -0 iocs.c ■• 丄 10 cs 


MS - C 7.0 互換の日本語文字処理ライブラ 

♦libmb.a 

_ I リ，つまりンフト JI 。 マノレナノ'イトコー 

ドの日本語文字列を扱う関数が含まれています。 ‘^ mb ” というのはマルチバイトを 
意味しています。これらの関数を使ったプログラムを作成する場合は，このライ 
ブラリをリンクしてください。このライブラリは GCC ， XC いずれの場合も自動 
的にはリンクされませんから，自分で明示的に指定する必要があります 。 GCC 
ならば， “- lmb ” というオプションを指定してください 0 

たとえば，マルチ八イト関数を使用するというブログラムがあると 
します。これを GCC を使い，最適化ありでコンパイルするには次のようにタイ 
プします。 


A:\> gcc -0 multi.c -lmb 
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GCC の “- p ” オプションや “- a ” オプ 
ションで利用するプロファイラが含まれ 
ています。このライブラリは， GCC でこれらのオプションを指定したときに自 
動的にリンクされます。ただし，このライブラリは GCC の機能を利用するため 
のものなので，では使用できません。 

プロファイラを用いると， “- p ” オプションの場合ではどの関数が何回呼び出さ 
れ，実際にどれだけの時間を消費したかを，また“- a ” オプションの場合ではど 
の論理ブロックを何回通過したかを統計として計算し，プログラム終了時に標準 
出力に出力します。 

それでは，次の List 1-4 というプログラムを使ってプロファイラの実際の使用 
例を見てみましょう。 


♦ libprol.a 


List 1-4 •プロ ファイルライブラリの 使用例 


1： /* 

2 : ** profile.c : 

3: ** 1 から 5 までの数字を表示する 

4: */ 

5 : # include <stdio.h> 

6 : 

7: void hello (int i) 

8: { 

9 : printf ("count = # /,d\n", i); 

10： > 

11 : 

12 : int main (void) 

13: { 

14: int i; 

15: 

16: for (i = 0; i < 5; i++) 

17: hello (i); 

18 : return 0; 

19: > 


上記のプログラムを GCC の “- p ” オプシヨンをつけてコンパイルする手順と， 
できあがった実行フアイルの実行結果を下図に示します。 


A: \> gcc -0 -p profile.c 

A:\> profile 

count = 0 

count =1 

count = 2 

count = 3 

count =4 

count = 5 

Function main : 0.000 sec(s) 

Function hello : 0.000 sec(s) 

A:\> 


1 time(s) 
5 time(s) 













この表示例では， main 関数が1回， hello 関数が5回実行され，それぞれの 
関数で消費した時間が0.000秒（測定限界以下）だったことを表しています。 

ただし，プロファイラの測定は i / 100 秒単位であり，ほとんど瞬時に通過してし 
まうような短い関数では，かなり測定誤差が出てしまいます。このことは，あら 
かじめ了解しておいてください。 


- ~~: SCSI 装置を操作する SCSI コールライ 

_ブラリが含まれています 0 SCSI コール 

を使ったプログラムを作成する場合は，このライブラリをリンクしてください。 
XC では，この SCSI コール ライブラリは DOS コール ライブラリに含まれます 
が， ZJ 忍 (7 では独立したライブラリです。このライブラリは GCC ， AX 1 いずれの 
場合も自動的にはリンクされませんから，自分で明示的に指定する必要がありま 
す。 GCC ならば， “- lscsi ” というオプションを指定してください。 

たとえば， SCSI コールを使用する “ scsi . c ” というプログラムがあるとしま 
す。これを GCC を使い，最適化ありでコンパイルするには次のようにタイプし 
ます。 


A:\> gcc -0 scsi.c - 丄 scsi 


libsignal.a 


は同ープロセス内にかぎってです 
が， POSIX .1 で規定されたシグナル機構 
に似たシグナルインタフェイスを提供しています。しかし，この機能は非常に微 
妙な位置付けにあります。 

ZJ 忍 C ではこのシグナルインタフヱイスをエミュレートするために割り込みを 
使用したり，システムの割り込みベクタを書き換えるなど，やや危険な処理をし 
ています。また，のシグナルインタフヱイスはサイズ的にも大きくなってい 
ます。そこで標準では，この機能は組み込まないような設定になっています。も 
しシグナルインタフェイスを利用したいのならば，自分で明示的に指定する必要 
があります。 GCC ならば，“- lsignal ” というオプションを指定してください。 

たとえば，シグナルインタフヱイスを使った“ signal . c ” というプログラムが 
あるとします。これを GCC を使い，最適化ありでコンパイルするには次のよう 
にタイフ°します。 


A:\> gcc -0 signal.c - 丄 signa 丄 


♦libsuper.a 


スーパーバイザモードでの実行をサポー 
卜するライブラリが含まれています。普 


通，を使用して作成されたプログラムはユーザモードで実行されますが，こ 
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3) ただし， MC 68000につい 
て十分な知雄がないなら， 
このライブラリを使って 
スーパーパイザモードで 
実行することは避けてく 
ださい0 


のライブラリをリンクすると，最初から最後までスーパーバイザモードで実行さ 
れるようになります。 

これは特に X 68000 で，数値演算プロセッサポードをもっている場合に有効 
です。は起動時に数値演算プロセッサボードの有無を調べ，もしボードが 
あれば MC 68881 を I / O 経由で直接駆動しますが，このときスーパーバイザモード 
と ユーザ モードの切り替えが発生します。このライブラリを用いて最初からスー 
パーバイ ザ モードで実行すれば，切り替える必要がなくなるので，高速に実行で 
きるようになります 3 )。ただし X 68030 では I / O を経由せず，直接 MC 68882に 
浮動小数計算させることができるため，このライブラリは X 68030 では意味が 
ありません。 

このライブラリは GCC ， XC いずれの場合も自動的にはリンクされませんか 
ら，自分で明示的に指定する必要があります。 GCC ならば， “- lsuper ” という 
オプションを指定してください。 

たとえば， “ fastmath . c ” というプログラムがあるとします。これを GCC を 
使い，最適化ありでコンパイルするには次のようにタイプします。 


A:\> gcc -0 fastmath.c -lsuper 


； LIBC は， POSU で規定されている夕 

_イムゾーンの処理をサポートしています。 

しかしごく普通にプログラミングする場合は，タイムゾーンについてそれほど意 
識することはありませんし，日本以外の時間帯を気にして使用することもあまり 
ありません。そこででは，環境変数 TZ を用いたタイムゾーンの処理を2通 
り用意してあります。 

1 つは pas/u の機能をすべてサボートしたもの，そしてもう 1 つは 日本で使 
用することを前提とした固定処理タイプのものです。後者は固定的な処理とはい 
え，日本国内で使用するぶんには問題ありませんし，前者のサイズが非常に大き 
いこともあり，では，標準では後者の固定タイプが使用されています。も 
し， POS / A ： •ブタイプの完全なタイムゾーン処理を利用したいのならば，自分で明 
示的に指定する必要があります。 GCC ならば， “- ltz ” というオプションを指定 
してください。 

たとえば，タイム ゾーン 処理を使った“ time. C” というプログラムがあるとし 
ます。これを GCC を使い，最適化ありで コンパイルす るには次のようにタイプ 
します。 

A: \> gcc -0 time.c -ltz 
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幅広文字を扱うライブラリのうち， SVR 4 
や抓五で定義されているものが含まれ 
ています。幅広文字を使ったプログラムを作成する場合は，このライブラリをリ 
ンクしてください。このライブラリは GCC ， XC 7 いずれの場合も自動的にはリ 
ンクされませんから，自分で明示的に指定する必要があります。 GCC ならば， 
“- lw ” というオプションを指定してください。 

たとえば，幅広文字を扱う関数を使った“ wchar . c ” というプログラムがあると 
します。これを GCC を使い，最適化ありでコンパイルするには次のようにタイ 
ブします。 


♦libw.a 


A:\> gcc -0 wchar.c -lw 


❖ライブラリファイルの使い方 


LIBC のライブラ リファイルは， GCC でもでも使用することができます。 
本セクションではそれぞれのコンパイラで， L 7 BC を利用する手順について説明 
します。 


GCC で L 仿 C を利用するには，いくつ 
かの設定が必要です。まず ， ZJ 所 7 の lib 
ディレクトリの位置を，環境変数 lib に設定しなければなりません。たと 
えば， LIBC をイ ンストールするときに，インストールディレクトリとして 
“ A :\ usr \ lang ” を指定したならば，環境変数 lib には“ A :\ oisr \ lang \ lib ” を設 
定してください。なおパス名の区切りには，のほかに“/”を使うこともでき 
ます。 

次に環境変数 GCC 丄 IB を設定します。これは GCC がリンクするときに使用 
するライブラリの形態を指定するものです。が標準で提供しているライブ 
ラリは， ZCver.l の “.a” 形式のライブラリファイルなので“ .a” を指定します。 
もしあなたが ZC をもっているならば， LIB.X を使って “.a” 形式のライブラリ 
ファイルを，より高速な XC ver.2 相当の“ . 1” 形式のファイルに変換することが 
できます 4 )。この場合は環境変数 GCC 丄 IB には“. 1” を指定します。 

最後にライブラリのネーミング方法について指定します。 C 言語の標準ライ 
ブラリを例にすると， ATC ではこのライブラリは “ clib . a ” というファイル名で 
す。しかし L 忉(:では前後を入れ換えて“ libc . a ” としています。このネーミン 
グ方法は UNIX にしたがったものです。同様に XC の DOS コールライブラリ 
は “ doslib . a ” ですが， L 仿 C では “ libdos . a ” です。 GCC が正しいライブラ 
リをリンクできるように，また GCC の“-1”オプシヨンを使って必要なライブ 


♦ GCC で使う 


4) プログラム LIB.X の使い 
方については，ズ C のマ 
ニュアルを参照してくだ 
さい。 
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5) この方法での利用を強く 
勧めます。 


ラリを選択できるよう，どちらのネーミング方法を使うかを指定しなければなり 
ません。もしあなたが X 68 k Programming Series #1 Develop . に付属している 
GCC を利用しており，が標準で指定したファイル名のままで利用したけ 
れば 5 ),環境変数 GCC _ NO _ XCLIB に “ yes ” を指定してください。しかし，もしあ 
なたが古いバージョンの GCC しかもっていないか，または XC と同じネーミン 
グ方法を用いたければ，環境変数 GCC _ NO _ XCLIB を定義しないようにして ， LIBC 
のライブラリファイルを 1 C 形式にリネームしてください。 

以上のことをふまえ，自分の AUTOEXEC . BAT を書き換えます。もしあなたがコ 
マンドシェルとして C 0 MMAND . X を使っているならば，以下の行を加えてください。 


set 丄 id=A:\ usr\lang\lib 

set GCC_LIB=.a 

set GCC_NO_XCLIB=yes 


また， L /5 C のライブラリファイルを XC 形式の名前に変えるには，インストー 
ルしたの bin ディレクトリにある “ LIBNAME . BAT ” を実行してください。次 
のような画面が表示され，ライブラリ名が形式に変更されます。 


A:\> CD A:\usr\lang\bin 
A:\usr\lang\bin 〉 LIBNAME.BAT 

ライブラリの名称を XC 形式に変更します。 

変更 libc.a -- > clib.a 
変更 libdos.a -- > doslib.a 

中略 

変更 libw.a -- > wlib.a 
変更は無事終了しました。 

A : \usr\iang\bin> 


まず前項の LIBC を 「 GCC で使う」方 
法を読んでください。 XC で使うには，こ 
のうちの環境変数 lib を設定することとライブラリファイルのファイル名を XC 
形式に変更することが必要になります。このときは環境変数への設定において， 
パス名の区切り記号に必ず“\”を使用してください。 

もしあなたが L / jBC のインストール先ディレクトリとして “ A :\ usr \ lang ” を指定 
し，コマンドシヱルとして COMMAND . X を使っているならば，自分の AUTOEXEC.BAT 
に次の行を加えてください。 


♦ ZC で使う 
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set lib=A : \usr\lang\lib 


また， ZJ 忍 C のライブラリファイルを XC 形式の名前に変えるには， bin ディレ 
クトリにある LIBNAME . BAT を実行してください。 


A:\> CD A:\usr\lang\bin 
A:\usr\lang\bin 〉 LIBNAME.BAT 

ライブラリの名称を XC 形式に変更します。 

変更 libc.a -- > clib.a 
変更 libdos.a -- > doslib.a 

中略 

変更 libw.a -- > wlib.a 

変更は無事終了しました。 

A:\usr\iang\bin> 

A:\> 


❖ ライブラリファイルについて 


LIBC は の上位互換として作成され 
ており， ZC とは ソースコードレベルで 
非常に互換性があります。ですから，これまで^7用に開発してきた ソースコー 
ドを L / BC •用に書き換えることは非常に容易です。場合によっては，何も書き换 
えなくてもよい場合もあるでしょう。 

しかし，は XC •のもつ機能をすべて備えているわけではありません 。 LIBC 
にはのもっている機能のうち，次のものが欠けています。 


audio.h 

PCM 音源を操作する関数 

graph.h 

グラフィックスを描画する関数 

image.h 

イメージユニットを操作する関数 

mouse.h 

マウスを操作する関数 

music.h 

FM 音源を操作する関数 

sprite.h 

スプライトを操作する関数 


♦ との互換性 
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• stick.h 


ジョイスティックを操作する関数 


ただし，これらの高レベルの関数については少々手間はかかりますが ， iocs 
コールなどの低レベル関数によつて代用することができます。 


♦ との互換•性 


ZJfiC は舰 S - C 7.0 特有の関数，たとえば 
日本語文字列の操作や _ fullpatti 関数な 


どのファイル操作関数を互換性のために提供しています。 MS - C 7.0[ t , MS - C 6.0 
から閨数名など細かい部分が変わっていますから，に関する参考書も 


役に立つと思います。 


LIBC は A / VS 7 C で規定された標準ライ 
ブラリの仕様をほぼ満たしていますが， 
唯一，ロケールを十分にサポートしていません。でサポートしているロケー 
ルは C ロケールだけであり，それも正しいロケール処理にのっとっているわけで 
はなく，固定的にコーディングされています。ですからロケール関連の関数，た 
とえば setlocale 関数， strcoll 関数などを扱う場合には，このことを頭にいれ 
ておく必要があります。 

また，では A / VSJC で規定されている 「 A / VSJC 標準ではない閨数はその 
関数名は“」’で始まるべきである」という条項を満たしていません。 MS - C 7.0 
などでは厳密にこの条項を守っていますが， LIBC の場合 ，標準以外の関数が多 
すぎること，また従来のソースコードとの互換性などを考えたうえで，この条項 
を省くことにしました。 


♦ 克 / V 57 C との互換性 


♦ P 0 SJX .2 との互換性 


LIBC は P 0 SIX .1 で規定されたライブラ 
リのうち，約60%程度の関数を提供して 
います。提供されていない残り40%の関数群は，たとえばプロセスのフォーク 
であるとか，パイプの生成や端末操作といった OS に非常に依存するものなの 
で，実現できていません。また，提供されている関数もすベての仕様を満足して 
いるわけではなく，一部の機能は省略されています。これらについては Vol .2 の 
「 Programmer’s Reference 」 を参照してください。 


♦ サポートしていない関数 


にはインクルードファイルに定義 
されているにもかかわらず，実体のない 
関数が数多くあります。これらの未サポート関数は，今の Human 68 k の使用で 
は実現することができなかったり，実現できてもあまり使用されないだろうとい 


う判断で省かれているものです。 Human 68 k の改良や X 68030 の彳生能によっ 
ては•の将来のバージョンでサポートされる可能性もありますが，今の段階 
では決まっていません。 










Chapter 2 

LIBC プログラミング 


本章では 「 LffiC プログラミング」と題して， L /5(7 ライブラリを用い 
たプログラミング技法をトピックスごとに解説します0もともと C の標 
準ライブラリには，誰もがほしいと思うような関数がほとんどそろって 
います。単にその存在を知らなかったり，使い方がわからなかったりし 
て，ムダになっていることが意外と多いのではないでしょうか？ 

関数の「仕様」は VoL 2 で紹介するとして，ここでは具体的に，しかも 
普通はあまり詳しく触れられないようなトピックスについて，サンプル 
を交えて解説していきます。 





















































































































































































ライブラリー第 1 部 


1 ) jirc とは ソース レベルで互 
換性があります。 



❖ ファイルを調べる 


ファイルを作成したり，読み書きすることについてはよく書籍などで紹介され 
ていますが，ファイルを調べる方法についてはあまり詳しく解説されていないよ 
うです。本セクシヨンでは，ファイルとデイレクトリの調べ方およびその扱い方 
について解説します。 


指定したファイルを調べる関数には stat 
関数， fstat 関数， lstat 関数などがあ 
り， <sys/stat.li> に定義されています。 stat 関数はパス名を指定してファイル 
を調べ， fstat 関数はファイルハンドルからファイルを調べます。 lstat 関数は 
少し特殊で，通常ファイルを指定すると stat 関数と同一の動作をしますが，シ 
ンボリックリンクファイルの場合，シンボリックリンク先のファイルではなく， 
シンボリックファイルそのものを調べます。これらの関数でファイルを調べると， 
Table 2-1 のようなファイルステータスがわかります。 このステータスは 可能な 
かぎり， UNIX の stat 関数の返すファイル ステータスの 内容に近付けました 
が， Human68k のファイル構造では完全に UNIX と同一にはできませんでし 
た。しかし XC の stat 関数とは，上位互換 1 )になっていますので， XC で求めら 
れるファイル ステータスは すべて求めることができます。 

XC と比較して，特に拡張された仕様は以下のとおりです。 

• st_dev, st_rdev により仮想ドライブ，仮想ディレクトリの判定が可能 

• st.size はディレクトリサイズも求められる 

• st_ino が疑似 i-node 番号を返す 

• シンボリックリンク先がデバイスドライバの場合も調べられる 

• ファイルモードがほぼ UNIX 互換になっている 

•1st at 関数がある 

簡単な stat 関数の使用例を List 2-1 に示します0 


♦ 指定したファイルを調べる 
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Table 2-1• stat 構造体の内容 


メンバ 名 

解説 

dev_t st.dev 

物理ドライブ番号 

ino_t st_ino 

物理ドライブ X 16777216 +先頭セクタ番号 

mode_t st_mode 

ファイルモード 

nlink.t st_nlink 

ファイルのリンク数を表すが，つねに 1 

uid_t st_uid 

ファイル所有者識別子を表すが，つねに 0 (root) 

gid_t st.gid 

ファイルグループ識別子を表すが，つねに 0 (root) 

dev_t st_rdev 

論理ドライブ番号 

off_t st.size 

ファイルサイズ，デイレクトリサイズ 

time.t st_atime 

最終アクセス時間を表すが，つねに stjntime と同じ 

time_t st_mtime 

最終変更時間 （ UTC) 

time_t st.ctime 

最終状態変更時間を表すが，つねに stjntime と同じ 


List 2-1• stat 関数を用いたサンプルプログラム 


2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 


/* 

ホ * sttest.c: 

** "C:/COMMAND .X" を stat 関数で調べる 

*/ 

#include <stdio.h> 
frinc 丄 ude <errno.h> 
ftinc 丄 ude <time.h> 

#include <sys/stat.h> 


int main(void) 

{ 

/* 構造体の宣言 */ 
struct stat st; 

/* ermo の初期化 */ 
errno = 0; 

/* stat 関数を呼び出す */ 
if (stat ("C:/COMMAND. X", &st)) { 
perror ("stat"); 
return; 

} 


/* 戻り値の内容を表示する */ 


printf 

(•， 

st_ino 

# /,08x\n" , st. st_ino); 

printf 

(" 

st_nlink 

7od\n", 

st.st_nlink); 

printf 

(_， 

st_uid 

# /.d\n", 

st.st_uid); 

pnntf 

(_， 

st_gid 

# /od\n", 

st.st_gid); 

printi 

(_， 

st_rdev 

%d\n _，， 

st.st_rdev); 

printf 

(" 

st_dev 

# /.d\n", 

st.st_dev); 

printf 

(_， 

st_mode 

70060 \n 

",st.st_mode); 

printf 

(" 

st_size 

# /.d\n", 

st.st_size); 

printf 

(•_ 

st_mtime 

y.sXn", 

ctime (&st.st_mtime)); 

return 

0 ； 




















この プログラムを コンパイルし 実行させると，画面には次のように表示され 
ます。 


A:\> gcc -□ sttest.c 


A:\> sttest.x 


st_ino 

02000050 

st_iuink 

1 

st_uid 

0 

st 一 gid 

0 

st_rdev 

2 

st_dev 

2 

st_mode 

100777 

st_size 

28382 

st_mtime 

Thu Feb 2512:00:00 1993 


A:\> 


A:\> DIR C:\COMMAND.X 


\HUMAN _Ver3 
1 ファイル 
ファイル使用量 
COMMAND 


C:\ 

1006K Byte 使用中 
28K Byte 使用 
X 28382 93-02-25 


215K Byte 使用可能 
12 : 00:00 


A:\> 


指定したディレクトリにどのようなファ 
イルが存在するのか調べるには，ディレ 
クトリストリームを用います。ディレクトリストリームは stdio ライブラリの 
ファイルストリームと同じように，ディレクトリエントリの構造をおおいかくし， 
簡単に操作できるようにするものです。 

ディレクトリストリームを操作する関数には opendir 関数， readdir 関数な 
どがあり，く dirent .li> に定義されています （Table 2-2 参照)。このディレクト 
リストリームの DIR 構造体の構造は Table 2-3 のように定義されていますが，通 
常，ユーザがこの構造体のメンバを参照することはまずありません。 

ユーザが実際に参照するのは， readdir 関数で返される dirent 構造体で， 
Table 2-4 のように定義されています。ユーザは readdir 関数を 1 回呼び出すご 
とに，ディレクトリ中で検索したファイルを1つずつ取り出すことができます。 
またこのとき， d_ino には， st at 関数の st_ino と同じ値が代入されます。 


Table 2-2 •ディレクトリストリーム関数一覧 


関数名 

解説 

opendir 関数 

デイレクトリストリームをオーブンする 

closedir 関数 

デイレクトリストリームをクローズする 

readdir 関数 

次のディレクトリエントリ構造体のボインタを返す 

seekdir 関数 

ディレクトリストリームの操作位置を変更する 

rewinddir 関数 

ディレクトリストリームの操作位置を先頭に変更する 

telldir 関数 

ディレクトリストリームの操作位置を返す 


♦ ディレクトリを調べる 
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Table 2-3* DIR 構造体 

メンバ名 

解説 

struct _filbuf filesbuf 

_dos_files 関数で取得した構造体 

long loc 

現在のファイルストリーム位置 

long ii 丄 emax 

デイレクトリのファイル数 

struct dirent *dp 

ディレクトリエントリ構造体へのポインタ 


Table 2-4•dirent 構造体 

メンバ名 

解説 

ino_t d_ino 

検索したファイルの i-node 番号 

char d Qame [NAME MAX + 1] 

検索したファイル名 


簡単な使用例を List 2-2 に示します。 


List 2-2 •ディレクトリの内容を表示する 


1 : /* 

2 : ** dirtest.c: 

3: ** C: ドライブのルートディレクトリに 

4: ** 存在するファイルをすべて表示する 

5: */ 

6: #include <stdio.h> 

7 : #include <dirent.h> 

8 : #include <errno.h> 

9: 

10 : int main (void) 

11 ：{ 

12: /* 構造体の宣言 */ 

13: DIR *dirp; 

14: struct dirent *dp; 

15: 

16: /* errno の初期化 */ 

17 : errno = 0; 

18: 

19: /* ディレクトリをオーブンする */ 

20: dirp = opendir ("C:/") ; 

21: if (dirp == NULL) { 

22: perror ("opendir"); 

23: return; 

24: } 

25: 

26: /* ファイルが見つからなくなるまで表示する */ 

27: while ((dp = readdir (dirp)) != NULL) 

28: printf (" # /,08x : # /,s\n" , dp->d_ino, dp->d_name); 

29: 

30: /* ディレクトリをクローズする */ 

31: closedir (dirp) ; 

32: 

33 : return 0; 

34: > 


この プログラムを コンパイルし 実行させると，画面には次のように表示され 
ます。 
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2) アイノードと読みます。 


3) lstat 関数を用いると，当 
然 i - node は異なります。 


A: \> gcc -0 dirtest.c 


A: \> dirtest.x 
02000000 : \HUMAN _Ver3 


020000 Ob 
02000044 
02000045 
02000046 


: HUMAN.SYS 
: CONFIG.SYS 
: KEY.SYS 
: USKCG.SYS 


0200004 e : BEEP.SYS 


0200004 f : 
02000050 : 
0200006c : 
0200006 d : 
02000179 : 
02000191: 
0200035 e : 
020003 c3 : 
020003 c9 : 


STARTUP.ENV 

COMMAND.X 

AUTOEXEC.BAT 

SYS 

HIS 

BIN 

BASIC2 

ASK 

ETC 


A:\> DIR C:\ 

\HUMAN _Ver3 C:\ 


13 ファイル 1006 K Byte 使用中 215K Byte 使用可能 


ファイル使用量 41K Byte 使用 


CONFIG 

SYS 


443 

93-02-25 

12:00:00 

KEY 

SYS 


712 

87-05-15 

12:00:00 

USKCG 

SYS 


8028 

87-05-15 

12:00:00 

BEEP 

SYS 


1023 

93-02-25 

12:00:00 

STARTUP 

ENV 


33 

90-05-15 

12:00:00 

COMMAND 

X 

28382 

93-02-25 

12:00:00 

AUTOEXEC 

BAT 


162 

93-02-25 

12:00:00 

SYS 


<dir> 


93-02-25 

12:00:00 

HIS 


<dir> 


93-02-25 

12:00:00 

BIN 


<dir> 


93-02-25 

12:00:00 

BASIC2 


<dir> 


93-02-25 

12:00:00 

ASK 


<dir> 


93-02-25 

12:00:00 

ETC 


<dir> 


93-02-25 

12:00:00 


A:\> 


ino または i - node 2 ) と呼ばれるインデッ 
クスノードは，ファイルの指標ノードと 
して UNIX のファイルシステムで用いられている概念です。実際 ， UNIX 
の i - node の情報は複雑で，そのなかには「ファイルのディスク上の位置」，「ファ 
イルの所有者 j ，「ファイルのアクセス許可」，「アクセス時刻」などが含まれます。 

しかし UNIX と Human 68 k では，ファイルシステムの概念が異なるため， 
LIBC では Human 68 k のディレクトリエントリを i - node とみなし，疑似的 
に i - node 番号が重複しないよう，以下の計算式で値を求めています。 


♦ インデックスノード 


物理ドライブ X 16777216 +先頭セクタ番号 


この i - node 番号を用いると， i - node 番号を比較するだけで，簡単にシンポ 
リックリンクなどで同じファイルを指しているかどうかを判定することができま 
す 3 )〇 
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Table 2-5 • 拡張 UNIX ファイルモード設定値 


マクロ 

意味 

所属 

S—IX0TH 

第 3 者実行 

UNIX 

S.IW0TH 

第 3 者書き込み 

UNIX 

S-IR0TH 

第 3 者読み込み 

UNIX 

S—IXGRP 

グルーブ実行 

UNIX 

S_IWGRP 

グループ書き込み 

UNIX 

S.IRGRP 

グループ読み込み 

UNIX 

S.IXUSR 

オーナー実行 

UNIX 

S.IWUSR 

オーナー書き込み 

UNIX 

S.IRUSR 

オーナー読み込み 

UNIX 

S-ISVTX 

スティッキービット（つねに 0) 

UNIX 

SJESGID 

Set GID ビット（つねに 0) 

UNIX 

S_ISUID 

Set UID ビット（つねに 0) 

UNIX 

S_IFIF0 

FIFO ( つねに 0) 

UNIX 

S_IFCHR 

キャラクタデバイス 

Human68k/UNIX 

S_IFDIR 

ディレクトリ 

Human68k/UNIX 

S.IFBLK 

ブロックデバイス 

UNIX 

S—IFREG 

通常ファイル 

Human68k/UNIX 

S.IFLNK 

シンボリックリンク 

Human68k/UNIX 

S—IFSOCK 

ソケット（つねに 0) 

UNIX 

S_IRD0NLY 

リードオンリー 

Human68k 

S.IFV0L 

ボリュームファイル 

Human68k 

S_ISYS 

システムファイル 

Human68k 

S.IHIDDEN 

隠しファイル 

Human68k 

S.IEXBIT 

実行ビット 

Human68k 


ファイルモードとは Human 68 k のファ 
イルアトリビュートのことですが ， LIBC 
の chmod 関数， stat 関数などで用いるファイルモードは UNIX との互換性を確 
保するために変更/拡張されています。そのためファイルアトリビュートとは呼 
ばずに，拡張 UNIX ファイルモードと呼ぶことにします。ただし DOS コールラ 
イブラリでは， XC と同じファイルアトリビュートを使用します。 

拡張 UNIX ファイルモードと Human 68 k アトリビュートは異なる 

拡張 UNIX ファイルモードの値は ， Table 2-5 のように定義されています。し 
かし，拡張 UNIX ファイルモードを参照する場合は，次のことに注意してくだ 
さい。 

また， ファイル モードは下位16ビットこそ UNIX の stat 関数の返す フ ァイ 
ルステータスの内容と同じになりますが， Human 68 k の ファ イル構造では完全 
に UNIX のものとは同一にはできないため，上位16ビットとビットが設定され 
る条件が異なる場合もあります。 


♦ ファイルモード 
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• 実行属性/書き込み属性は，オーナー/グループ/第3者すベて同じ値が設定 
される 

• 読み込み属性はつねに有効である 

• S — IRDONLY が設定されないかぎり（たとえシステムファイルでも），書き込み 
属性/読み込み属性はそのまま有効である 
• 実際に実行属性がなくても，拡張子が‘. X ’， ‘. R ’，‘. Z ’ のものには実行属性 
がっく 

• 実際に実行属性がなくても，ディレクトリには実行属性がつく 
• シンボリックリンクファイルは，つねに読み書き属性/実行属性がつく 


❖ファイルの構造 


本セクシヨンでは，ディスクマップおよびディレクトリエントリの構造につい 
て，ごく簡単に説明しておきます。 


Human 68 k の管理するディスクマツ 

プは，デバイスによって領域の大きさ 
やセクタ番号などが変わりますが，おおまかに次のようになっています。 


♦ ディスクマップ 


• IPL プログラム領域 0 S を読み込むために必要なプログラムの領域 

•第 1 FAT 領域 データエリアの使用セクタの連鎖（チェイン）状 

態を示すテーブル 
• 第 2 FAT 領域 使用されていない 


• ルートディレクトリ領域 ルートディレクトリのディレクトリエントリの 

領域 

• データ領域 実際のファイル内容の領域 


デイレクトリエントリは個々のファイルの 
情報を記憶しておくためのもので，ルー 
トディレクトリとサブディレクトリのなかに存在します。また，ディレクトリエ 
ントリは1ファイルにつき32バイトで ， Table 2-6 のような構造をもっていま 
す。また，ディレクトリエントリに含まれる「ファイルアトリビュート j , 「時刻」， 
「日付」の各フィールドは，それぞれ Table 2-7 ， Table 2-8, Table 2-9 のような 
ビット構成になっています。 


♦ デイレクトリエントリ 
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T^ble 2-6 •ディレクトリエントリの構造 


オフセット 

内容 

+$00. B 

ファイル名 1 ( あまった部分は $20) 

+ $08.B 

ファイル拡張子（あまった部分は $ 2 〇 ) 

+ $0b.B 

ファイルアトリビュート （Table 2-7 参照） 

+ $0c.B 

ファイル名 2 ( あまった部分は $00) 

+$16. W 

時刻 (Table 2-8 参照） 

+$18. W 

日付 （Table 2-9 参照） 

+ $la.W 

先頭 FAT 番号（上位 / 下位が逆） 

+ $lc.L 

ファイルサイズ 


Table 2-7 •ファイルアトリビュートのビット構造 


ビット位置 

ファイルアトリビュート 

bit 0 

読み込み専用 

bit 1 

不可視 

bit 2 

システム 

bit 3 

ボリューム 

bit 4 

ディレクトリ 

bit 5 

通常のファイル 

bit 6 

Human68k では未使用だが，フリーウェアの “lndrv.x ” が使用する 

bit 7 

Human68k では未使用だが，フリーウェアの “execd.x ” が使用する 


Table 2-8 •時刻フィールドのビット構造 


ビット位置 

時刻 

bit 15〜11 

時 

bit 10〜05 

分 

bit 04〜00 

秒 X2 


Table 2-9 . 日付フィールドのビット構造 


ビット位置 

日付 

bit 15〜09 

年 

bit 08〜05 

月 

bit 04 〜〇〇 

日 
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❖パス名 


LIBC では， XC に比べてパス名の扱いが拡張されており，従来とは扱い方が異 
なっている場合があります。 


L / 所:のパス名の扱いは ZC より柔軟で 

♦ のパス名の扱いについて 

_ I す0 ZJ 5 C •では，関数が返すパス名の区 

切り文字は，一貫して“/”が使用されますから，パス名解析が非常に簡単に行え 
ます。ただし L/BC においても， DOS コール ライブラリは Human 68 k のバー 
ジョンと仕様に依存します。 

関数に与えるパス名には，次のような規約があります。 

• ドライブ名は大文字でも小文字でもよい 
• パス名の区切り文字は“\”または“/”のどちらでもよい 
• パス名の最後に“または“/”が付加されていてもよい 

また関数が返すパス名は，次のような規約にしたがっています。 

• ドライブ名は大文字にする 

• パス名の区切り文字は“/’，とする 

• パス名の最後に“\”および“/”は付加されない 
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❖数値の表現形式 


ZC や GCC をはじめとする最近の一般的な C コンパイラがどのようにして実 
数を扱っているか，その表現形式について説明します。 


コンピュータのメモリは有限ですから， 

♦ 実数の表現 

_:_無限にある数のうち限られた範囲しか扱 

えません。このような制限あるコンピュータ上で小数点を表現するために，固定小 
数点 （ Fixed point representation) と 浮動小数点 （ Floting point representation ) 
という 2 通りの表現方法があります。固定小数点というのは，小数点の位置を固 
定し，整数部と小数部の桁数をあらかじめ決めて，その範囲内で表現する方法で 
す。また逆に，浮動小数点とは，小数点の位置を指数の形式で記憶しておく方法 
です。 

固定小数点の場合は「扱える数の範囲が狭いが，演算が簡単で速い」のに対し， 
浮動小数点では逆に「扱える数の範囲は広いが，演算が複雑で固定小数点演算よ 
り遅い」という特長があります。そして，これらの2つの表現方法のうち， C 言 
語では実数の表現に浮動小数点を用いています。 GCC が扱える実数型は， Table 
2-10 のとおり 1 )です。 


♦ IEEE 規格の2進浮動小数点形式 


浮動小数表現にも表現方法はいろいろあ 
りますが，現在の一般的な C コンパイ 


ラでは，おもに米国電気電子学会 (The Institute of Electrical and Electronics 
Engineers Jnc.) の ANSI/IEEE Std 7 54 _1 985 ( 以下， 「IEEE 2) 」と略す）規格の 
フォーマットが採用されています。 


l)long double 型もあり 
ますが， X 68 k Program - 
mms Sreics #1 Develop . 
に付属している GCC 
では， double 型と同じ精 


度として扱われます。 


2) 「アイ•トリプル•イ 
と読みます。 


Table 2-10 • 

各実数型 



型 

サイズ 

範囲 

型の分類 

float 型 

32 ビット 

1.18 X 10— 38 〜 3.40 X 10 38 

単精度浮動小数点 

double 型 

64 ビット 

2.23 x 10— 308 〜 1.80 x 10 308 

倍精度浮動小数点 
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3) IEEE 以外では，有効数 
字を仮数 （ mantissa ) と呼 
ぶことが多いようです。 


float 型（単精度浮動小数点 ) 


MSB 

V 


LSB 

H . . . e 

...1 . 

f 

| 

3130 

2322 


0 


s - 符号部 （ 0: 正負） 

e- 指数部（符号なし 8 ビット 2 進整数，ただし e=0, e=0xff は特殊数 ) 
f- 有効数字部 （ 23 ビット 2 進固定小数点実数） 

double 型（倍精度浮動小数点） 


MSB 

▽ 


LSI 

l s l. e 

— 1. 

f 

.1 

6362 

5251 


0 


s - 符号部 （ 0: 正 1: 負） 

e- 指数部（符号なし 11 ビット 2 進整数，ただし e=0, e=0x7ff は特殊数） 

f- 有効数字部 （ 52 ビット 2 進固定小数点実数） 

Fig.2-1 • 浮動小数点を構成するビットフィールド 

IEEE フォーマットを利用するメリットは，同じ IEEE フォーマットを使用して 
いる C コンパイラおよびライブラリであれば，機種や OS が異なっていてもつね 
に同じ結果が得られ，演算精度を一定に保つことができることです。 

IEEE 形式の2進浮動小数点を構成するビットフィールドは， Fig . 2-1 のように 
定義されています。このフィールドには「符号 （ sign )」 ，「指数 （ exponent )」 ，「有 
効数字 （ significant ) 3) 」の3つのフィールドがあり，これらの組み合わせによっ 
て実数を表現しています。 

また，ビットフィールド中の小数点位置は▽の位置にあり，正規化数は l<f <2 
の範囲を表しています。ただし，正規化数の最上位の1ビットが省略されている 
ため，有効数字は1+ /となり，実際に格納される/の範囲は〇ざ/<1となり 
ます。これらのフィールドは Table 2-11 のように組み合わされ，次のように分類 
されます。 


〇 非数 f Not a number ) 

数値的に，無限大より値の絶対値が大きい数を非数 （ NaiV ) といいます。規 
定上，非数は有効な値としては扱われず，無効演算の結果として返されます。 
また，非数についても符号は有効です。 

〇無限大 （ Infinity) 

演算の結果，値の絶対値が正規化数の最大値より大きくなった場合，その結 
果を無限大といいます。つまり演算がオーバーフローした場合，結果は無限 
大になります。無限大も0と同様に符号が有効で，オーバーフローした値の 
符号がそのまま用いられます。また， 一00 <+〇〇の関係が成り立ちます。 
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Table 241• IEEE 規格の 2 進浮動小数点形式の表現できるフィールドの組み合わせ 


表現値 

符号部 

指数部 

有効数字部 



111...111 

1111…1111 

非数 (NaN) 

0/1 

111…111 

0000- - 0001 

無限大（〇〇 ) 

〇 /1 

111…111 

0000- - 0000 



111…110 

1111..-1111 



111...110 

1111…1110 



111-.-110 

1111.1101 

正規化数 

0/1 

000 .. 001 

0000- - .0010 



000•- 001 

0000- - 0001 



000….001 

0000- - .0000 



000 .. 000 

1111…1111 

非正規化数 

0/1 

000 - .000 

0000- - 0001 

0 

0/1 

000•- 000 

0000- - 0000 

単精度 

< —1 ビットー > 

<—8 ビッ 1-- 

—23 ビット — 

倍精度 

—1 ビットー ♦ 

<—11 ビットー > 

—52 ビット — 


〇 正規化数 （Normal number ) 

正規化された浮動小数点のことです。正規化とは，浮動小数点の有効数字の 
フィールドの最上位の桁が0以外の数になるように，指数のフィールドを調整 
することです。たとえば +0.000123 xlO 45 は，正規化すると +1.230000 X10 41 
になります。 

〇 非正規化数 （Denormalized number ) 

演算の結果，値の絶対値が正規化数の最小値と0の間にある数を非正規化 
数（デ ノーマル 数） といい ます。普通，正規化数の最小値より小さい数は アン 
ダーフローと して0 と 認識されてしまいます。しかし IEEE 規格では， アン 
ダーフローが 発生した場合にもこのような特殊形を用いて，できるだけ値を 
失わないようにしています。そのため非正規化数の有効数字 フィールドの 最 
上位は，つねに0になります。 

〇 0 ( Zero ) 

指数/有効数字の両方のフィ ー ルドが と もに0の状態をいいます。 IEEE 規格 
では，0の場合でも符号は有効で， 一0.0 と +0.0 の2つの0が存在します。 
これを 符号つき〇 ( Signed zero ) といい， 一1.0 に 近い 0 か， +1.0 に 近い 0 
かを表しています。ただし，数がもつ量は同じ〇.◦なので， 一0.0 = +0.0で 
あることに変わりはありません。また「真の」0は， IEEE 規格では +0.0 に 
なります。 
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❖数学関数の使用について 


の数学関数は，状況に応じて柔軟に動作するように設計されています。最 
良の結果を得るために，説明をよく読んで使用してください。 

数学関数とは「三角関数」，「対数」，「平 
方根」など，おもに実数型の演算を行う 
ための関数のことで， < math . li > に定義されています。これらには多くの関数が 
ありますが，には A / VSJC で規定されるすべての関数がそろっています。 

数学関数の簡単な使用例を List 2-3 に示します。このプログラムは LC 発振周 
波数を L ， C の定数から求めるものです。 


♦ 数学関数とは 


List 2-3 •数学関数の使用例 


1 : /* 

2 : ** mathtest.c: 

3: ** LC 発振周波数を求めるプログラム 

4: ** f = 1/(2 n * sqrt(LC)) 

5 : */ 

6 : # include <stdio.h> 

7 : #inelude <math.h> 

8 : 

9 : int main(void) 

10 ： { 

11: double 1=1.45, c =19.4, hz; 

12 : 

13: printf ("コイル =%.3f pi H\n",1); 

14: printf ("コンデンサ =%.3fpF\n", c); 

15: 

16: /* 単位変換 */ 

17 : 1 *=le-6; 

18: c *=le-12; 

19: 

20: /* f =1/(2 7t * sqrt(LC)) */ 

21: hz =1 / (M_PI * 2 * sqrt (1 * c)); 

22 : 

23: /* 周波数の単位を MHz で表示する */ 

24: printf ("周波数 = 7..3fMHz\n" , hz / le6); 

25: 

26 : return 0; 

27: } 


のプログラムを コンパイルし， 実行させると次のように表示されます。 
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A:\> gcc -0 mathtest.c 
A:\> mathtest.x 
コイル = 1.450 m H 

コンデンサ = 19.400 pF 
周波数 = 30.008 MHz 

A:\> 


ZC では，ユーザが“ FLOAT 2. X ” か，ある 
いは “ FL 0 AT 3. X ，， のどちらの FLOAT パッ 
ケージ 4 )を組み込むかで，コプロセッサの有無を決定していました 5 )。しかし 
“ FL 0 AT 3. X ” などの場合，コプロセッサの処理時間に比べて FLOAT パッケージ呼 
び出しの才ーバーへッドがかなりありました。 

の数学関数は，コプロセッサの有無を起動時に自動的に判別します。つ 
まりコプロセッサが実装されていれば， FLOAT パッケージを呼び出さずに I / O コ 
プロセッサおよびコプロセッサ命令を直接使用して，ユーザの環境で最も高速に 
実行できるようにライブラリ内部の処理を切り替えます。そのため，ある数学関 
数を使うプログラムをコプロセッサをもっていないユーザが作成したとしても， 
何ら変更することなくコプロセッサ環境で高速に動作させることができます。 

現在 X 68000 シリーズのコプロセッサにはインタフェイスの違いにより，アク 
セス方法が2種類存在します。すなわち， X 68000 機種用に用いられる数値演算 
プロセッサボードがもつ I / O 制御によるコプロセッサ方式 6 )と， X 68030 機種に 
用いられている MPU 命令の一部として動作させる方式 7 )です。 

X 68000 および X 68030， コプロセッサの有無といった各環境における動作 
状態は， Table 2-12 のようになります。また，演算速度は一般に以下のような関 
係になります。 

コプロセッサ命令〉 I/O コプロセッサ〉 FLOAT パッケージ 

xc では， エラー 処理に相当の 
matherr 関数を使う方法が用いられて 
いましたが， LIBC では ，各数学関数の エラーは 関数内部で変数 errno に設定す 
るだけにとどめています。このとき， L 仿 (7 の数学関数で，変数 errno に設定さ 
れる値は Table 2-13 のとおりです。 


♦ L 仿 C の数学関数の仕様 


♦ 1仿 C の数学関数の特徴 


4) Human 68 k の ver .3 
からはコプロセッサ命 
令による演算を行う 
“FL0AT4.X” もあります。 

5 ) XC ver .2 以降では，新 
たに “FL0ATEML.L” ライ 
プラリが追加され， FLOAT 
パッケージなしでソフト 
エミュレート することが 
できます。 


6) 現在 “FPPP.X” の仕様に 
より， X 68030 では作 
成したコードがキヤッシユ 
オン時に動作不安定にな 
るため， X 68030 では 
使用不可になっています。 

7) X 68030 の 拡張 ス □ ッ 
卜に数値演算プロセッサ 
ボードを実装しても， I/O 
コプロセッサとして動作 
するのみで，コプロ セツ 
サ命令として動作させる 
ことはできません。 


Table 2-12 •各環境の動作状態 


マシン 

コプロセッサ有無 

動作モード 

X68000 

なし 

FLOAT パッケージ呼び出し 

X68000 

あり （ I/O) 

I/O コプロセッサ 

X68030 

なし 

FLOAT パッケージ呼び出し 

X68030 

あり （ I/O) 

I/O コプロセッサ（現在は無効） 

X68030 

あり 

コプロセッサ命令 
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Table 2-13 • 変数 errno の設定値の意味 


マクロ 

意味 

ED 0 M 

ERANGE 

引数が非数または計算範囲外だった 

演算結果が 才ーバーフロー または アンダーフローした 


Table 2-14 •数学関数のエラー時の戻り値 


変数 errno の値 

戻り値 

EDOM 

非数 

ERANGE 

非正規化数，無限大，非数 


8) yliVSJC 規格では，エラー 
番号の ERANGE が股定さ 
れるかどうかは機種依存 
と定義されています。 


9) 么幼 SZ ) あるいは SYSV で 
は， HUGE と定義されてい 
ることもあります。 


ただし “ FL 0 AT 2. X ”を使用した場合， “ FL 0 AT 2. X ”が非正規化数を返さないと 
いう 仕様のため， ERANGE が正しく設定されない場合があります 8 )。また フリー 
ウェアとして数多く存在する FLOAT パッケージの なかには，高速化のために値 
のチヱック 等を省いて いるもの もあり，使用する FLOAT パッケージに よっては， 
結果的に変数 errno が設定されなかったり，正常終了するにもかかわらず変数 
errno が設定され る こともあります。もし正確な演算をしたければ，コブ ロッサ 
を用いるか，あるいは純正の“ FL 0 AT 2. X ” を使用してください。 

ANSI ¢7規格では一般に正規化数を，また ERANGE エラ ーの場合は HUGE - VAL 9 ) を， 
数学関数の戻り値とするよう定義されていますが， LIBC では IEEE 規格にしたが 
い，可能なかぎり（たとえアンダーフローした数であっても），その値を返すよう 
にしています 。 Table 2-14 に L / BC 数学関数の エラーの 戻り値を示します。また， 
“ FL 0 AT 2. X ” を使用した場合は非正規化数は返りません。そのことを念頭に置い 
て使用してください。 


10 )FLOAT パッケージまたは 
コプロセッサに存在しな 
い数学間数は，内部間数が 
一部ない場合があります。 


1 1) マクロは < matti . h > をイ 
ンクルードする前に定義 
してください。 


前述したように，1仿 C には1つの数学 
関数に対して 「 FLOAT パッケージ」， 「 I/O 
コプロセッサ直接駆動」，「コプロセッサ命令」の3種類 10 )の演算ルーチンが入っ 
ています。通常は関数内部でユーザの環境を判断して，それぞれのルーチンを呼 
び出しますが，さらに少しでも速くしたい場合には直接内部のルーチンを呼び出 
すことができます。 

この 内部 ルーチン もほかの標準数学関数と同じく グローバル 関数ですので，関 
数名が異なることとユーザの環境を判断しない部分を除けば，通常の数学関数と 
まったく同じ動作をします。また，各内部関数の関数名は Table 2-15 のように 
定義されます。もし，関数名を変えずに簡単に内部関数を使用したいならば，コ 
ンハ 。 イル 時に __DIRECT_FLOAT— (FLOAT パッケージ 呼び出し）， — DIRECT 一 10 FPU__ 
(I/O コプロセッサ)， __DIRECT_FPU„ (コプロセッサ命令） の 各 マクロ 11 ) のうちい 
ずれか1つを定義してください。それぞれ，内部関数が直接呼び出されます。 

たとえば P .54 の List 2-3 のプログラムを，内部関数呼び出しの形式でコンパ 
イルするには次のようにタイプします。 


♦ 数学関数の使用について 
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Table 2-15 •内部ルーチンの関数名 


動作環境 

マク ロ名 

関数名 （？？？ の部分は数学関数名） 

FLOAT ノヽ 0 ツケージ 

__ DIRECT _ FL 0 AT ._ 

_ fe _??? 

I/O コプロセッサ 

__ DIRECT _ I 0 FPU _. 

_ fpu .??? 

コプロセッサ命令 

__ DIRECTJFPU „ 

_f _??? 


A :\> gcc - D __ DIRECT _ FLOAT __ -0 mathtest.c 
A :\> gcc - D __ DIRECT . IOFPU — -0 mathtest.c 
A :\> gcc - D __ DIRECT _ FPU — -0 mathtest.c 


しかし，内部関数を直接呼び出すと，ユーザの環境に合わせて動作させること 
ができなくなります。つまり，同一環境のもとでしか動作しなくなります。もし 
フリーウェアなど，多くの人に配布するようなプログラムを作成するならば，こ 
の機能は用いないでください。 


❖コプロセッサ補足説明 


X 68000 と X 68030 におけるコプロセッサの位置付けについて，簡単に確認 
しておきます。 


コプロ セッサとは，メイン プロ セッサの 
アーキテクチャでは直接サポートされて 
いない命令，レジスタおよびデータタイプをプログラミングモデルに追加する 
MPU 周辺デノパス LSI です。そのなかの1つに数値演算コプロセッサが含まれ， 
MPU では演算できない多精度の整数演算/浮動小数点演算などを MPU の代わ 
りに演算します。 

数値演算コプロセッサには，コプロセッサ命令によって MPU 内部の命令の1 
つとして動作するタイプと， I / O を介してプログラムにより制御するタイプの2 
種類があります。 MC 68000の標準周辺デバイスのコプロセッサには MC 68881 と 
MC 68882がありますが，この2つの LSI は，コプロセッサ命令と I/O による制御の 
両方で使えるように設計されています 12 ただし，コプロセッサ命令は MC 68020 
以上の MPU でなければ実行できないため， X 68000 では I / O による制御でしか 
動作させることができません。また，コプロセッサ命令が1命令で処理できるの 
に比べて， I / O コプロセッサの場合，プログラムにより I / O を制御しなくてはな 
らないため，処理が複雑でしかも遅くなります。 


♦ コプロセッサとは 


12) MC 68882 は MC68881 に 
対して上位互換で，演 
算速度が速くなっていま 
す。ただし， I / O による 
制御で使う場合は少々異 
なるようです。 


♦ MC 68881 と MC 68882の判別方法 


List 2-4 に MC 6888 1と MC 68882の簡単な 
判別方法を紹介しておきます。この2つ 


のコプロセッサは，その内部に tt などの定数が書かれた ROM テーブルをもってい 
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13) 筆者が個人的に調べた 
データなので，未定義部 
分が異なる場合があるか 
もしれません。 


14) IEEE 規格のフオーマツ 
卜でサイズは96ビット 
ですが実際は80ビット 
データです。 


ますが，このテーブルの未定義部分にあたるオフセツト$01は MC 6888 1 と MC 68882 
では定数が異なり，このテーブルの違いによって判別することができます。コ 
プロセッサ内部 ROM の内容は ， Table 2-16 のようになっていました 13 )。内部 
ROM は拡張倍精度 14 )の定数なので， double 型で表現できないものは16進表示 
で表記しています。 


List 2-4# MC 68881 t MC 68882の判別方法 


1： /* 

2 : ** fputest.c : 

3: ** I/O に実装されている MC68881 と MC 68882 を判別する 
4: */ 

5: # include <stdio.h> 

6 : # include <sys/dos.h> 

7: 

8: /* インライン展開されると困るので，一応禁止する*/ 

9 : #pragma 11111 ne-functions off 
10: 

11:/* -m68881 を指定するからいらないけれど，一応指定する*/ 

12 : #pragma 68881 on 
13: 

14: double getfpurom () 

15: { 

16 : double result; 

17: 

18: /* 内部 ROM のオフセット $01 の内容を result に代入する*/ 

19: __ asm volatile ("fmovecr.x #$01, # /〇0": "=f" (result)); 

20: 

21: /* オフセット$01の内容を返す*/ 

22 : return result ; 

23: } 

24: 

25: /* スーパーバイザ移行前にコプロセッサに 1/0 アクセスされないように禁止する*/ 

26 : #pragma 68881 off 

27: 

28: void main(void) 

29: { 

30: double offset_l; 

31: int ssp; 

32: 

33: /* スーパーバイザに移行する*/ 

34: ssp = _dos_super (0) ; 

35: 

36: /* オフセット $01 を取得*/ 

37: ofiset_i = getfpurom () ; 

38: 

39: /* ユーザに戻る*/ 

40: if(ssp > 0) 

4丄： _dos_sut>er 、ssp ノ； 

42: 

43: /* オフセット内容を判別し，表示する*/ 

44: printf ("0FFSET[$01] = °/.f : ", offset.l) ; 

45: if(offset_l== 0.0) 

46: puts("MC68881 です。"）； 

47 : else 

48: puts ("MC68882 です。"）； 

49: > 
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Table 2-16 •コプロセッサ内部 ROM テーブルの内容 


0FS 

MC 68881 

MC 68882 

意味 

$00 

3.1415926535898 

3.1415926535898 

丌 

$01 

0.0 

7.9375031031668 

未定義 

$02 

7.992189890705 

7.992189890705 

未定義 

$03 

$200000007FFFFFFF00000000 

$200000007FFFFFFF00000000 

未定義 

$04 

0 

0 

未定義 

$05 

2.2250738585072 e - 308 

2.2250738585072 e - 308 

未定義 

$06 

1.1754942807574 e - 038 

1.1754942807574 e - 038 

未定義 

$07 

$00010000F 650809 C00000000 

$00010000F 650809 C00000000 

未定義 

$08 

$7FFF00 00401 E000000000000 

$7FFF00 00401 E000000000000 

未定義 

$09 

7.6805736963112 e + 304 

7.6805736963112 e + 304 

未定義 

$0A 

6.2307562302418 e + 034 

6.2307562302418 e + 034 

未定義 

$0B 

0.30102999566398 

0.30102999566398 

logio(2) 

$0C 

2.718281828459 

2.718281828459 

6 

$0D 

1.442695040889 

1.442695040889 

㈣ 2 (e) 

$0E 

0.43429448190325 

0.43429448190325 

logio(e) 

$0F 

0.0 

0.0 

+0.0 

$10 

0.0 

0.0 

未定義 

$2F 

0.0 

0.0 

未定義 

$30 

0.69314718055995 

0.69314718055995 

/n(2) 

$31 

2.302585092994 

2.302585092994 

ln(10) 

$32 

1 

1 

10° 

$33 

10 

10 

10 1 

$34 

100 

100 

10 2 

$35 

10000 

10000 

10 4 

$36 

100000000 

100000000 

10 8 

$37 

le + 016 

le + 016 

10 16 

$38 

le + 032 

le + 032 

10 32 

$39 

le + 064 

le + 064 

10 64 

$3A 

le + 128 

le + 128 

10128 

$3B 

le + 256 

le + 256 

10256 

$3C 

$46A 3000 0E319A0AEA60E91C7 

$46A 3000 0E319A0AEA60E91C7 

10 512 

$3D 

$4D 48000 0C 976758681750017 

$4D 48000 OC 97675868175 0C17 

エ01024 

$3E 

$5A 9200009 E8B3B5DC53D5DE5 

$5A 9200009 E8B3B5DC53D5DE5 

^02048 

$3F 

$752500000 46052028 A 20979 B 

S75250000C 46052028 A 20979 B 

1 q ‘1096 












しかし，この方法は未定義部分を参照しているので，将来 LSI チップ自体が変 
更されて使用できなくなるかもしれません。そのことには注意してください 
このプログラムを I/O コプロセッサ（この場合， MC 68881) を実装した状態で実 
行すると，次のようになります。 


A: \> gcc -0 -m 68881 fputest.c -ldos 
A:\> fputest.x 

OFFSET [$01] = 0.000000 : MC68881 です。 
A:\> 


ただし List 2-4 は I/O コプロセッサの判別だけで， I/O コプロセッサが実装さ 
れているかどうかについては調べていません。さらに，このプログラムは少々危 
険なコーデイングで， X 68 k Programming Sreies #1 Develop . に付属の GCC 
でしかコンパイルすることができません。もっと簡単に判別するために ， LIBC 
では- is 68881関数を提供していますから，こちらの使用をお勧めします。 
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❖ 暦時間 


本セクションでは時間の表現方法，協定世界時と地域時間の違いなど ， LIBC 
での日付と時間の取り扱いについて簡単に解説します。 


コンピュータ上で日付や時間を表現する 
方法は，実は多種多彩で， 0 S によって 
あるいはライブラリによって異っています。しかし一般には，暦時間というもの 
か'使われることが多いようです。 

暦時間というのは，英語でカレンダータイ厶 （Calendar time ) あるいはエポッ 
クタイム （Epoch time ) といいます。これらは，協定世界時である1970年1月1 
日午前〇時〇分〇秒 1 )から何秒経過したかを， long 型で表したものです。ただ 
し，この1970年という基点が曲者で，処理系によっては1900年，場合によって 
は1980年となっていたりして，混乱しています 2 )。このような基点のズレはあり 
ますが，その意味はいずれも処理系依存のエポックから何秒経過したかというこ 
とですから，大した問題ではありません。 

むしろ注意すべきなのは，暦時間と地域時間には関係がないということです。 
このことは勘違いしやすいことですから，はっきりさせておきましょう。繰り返 
しますが，暦時間は「協定世界時」で計算した1970年1月1日からの経過秒数 
のことであり，自分が住んでいる地域での地域時間（たとえば日本時間）で計算し 
た1970年1月1日からの経過秒数ではありません。 


♦ 暦時間とは 


1) この時刻をエポック（英 
語では epoch) と呼び 
ます。 

2) そのなかでは，1970年 
に設定している場合が多 
いようです。 


暦時間はつねに協定世界時である 


暦時間は， C ではく time 上〉で定義さ 
れる型で表現します。ただし， 
L / BC では型は long 型への typedef ですから，表現できる値は士 2 31 ま 
でであり，近い将来，おそらく 21世紀半ば 3 )には long 型で表現できなくなりま 
す。しかしそのような将来に，いまだに現在と同じ形で計算機を用いていると考 
えるのは，実にばかばかしいことなので問題とはならないでしよう。 


♦ 暦時間を表現する 


3) もし暇な人がいたら，実 
際に何年何月何日になる 
か計算してみましよう。 
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今の暦時間を求める 


今現在の暦時間を求めるには， time 関 
数を使います。ほかに暦時間を求める方 
法として ftime 関数がありますが，こちらはどちらかといえば古くさいインタ 
フェイスですから，ここでは解説しません。必要ならば Vol .2 のマニュアルを参 
照してください。 


List 2-5 • time 関数の使い方 


1 ：卜 

2 : ** time.c: 

3: ** どちらの関数も今現在の暦時間を求める 

4: */ 

〇: #include <time.h> 

6 : 

( : time_t getCalendarTime1(void) 

8: { 

9: /* NULL を指定するのが普通*/ 

10: return time (NULL); 

11 ：> 

12 : 

13 : time_t getCalendarTime2 (void) 

14: { 

15: time_t now; 

16: 

17: /* さもなければこういう使い方もできる*/ 

18: time (&now) ; 

19: return now; 

20 : > 


♦ 任意の暦時間を求める 


では，任意の日付/時間の暦時間を求め 
るにはどうすればよいでしょうか。その 


ためには mktime 関数を使います。 mktime 関数は，詳細時間 （ tm 構造体で表現) 
を time _ t 型に逆変換するための関数です。詳細時間については後ほど詳しく述 
ベますので，ここではサンプルプログラムを示すだけにとどめておきましょう 
(List 2-6 参照)。ただし， mktime 関数に指定する時間は地域時間で，協定世界時 
ではありません。このことには注意してください。 


mktime 関数には地域時間を指定する 


List 2 -(i •mktime 関数の使い方 


1 ： /* 

2: ** mktime.c: 

3: ** 日本時間1993年2月10日10時0分〇秒を暦時間に直す 

4: */ 

5: #include <time.h> 

6 : 

7: time_t convertTime (void) 

8: -C 

9 : struct tm t; 

10 : 

11: t.tm_sec =0; /* 秒*/ 
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12 

t.tm_min = 0; 

/* 

分 */ 

13 

t.tm_honr =10; 

/* 

時 */ 

14 

t.tm_mday =10; 

/* 

日 */ 

15 

t.tm_mon =1; 

/* 

月 •1 */ 

16 

t.tm_year = 93; 

/* 

年 - 1900 */ 

17 

t.tm_isdst =-1; 

/* 

夏時間を考慮： 

18 

return mktime (&t); 


19 

} 




♦ 暦時間の利点 


暦時間を用いると，2つの時間の差が簡 
単に求められます。たとえば暦時間を使 


えば，1992年10月3日5時17分30秒と1993年1月15日8時30分0秒とい 


う複雑な時間差は，単なる引き算1つで得られます。これをばか正直に秒/分/時 
の順番で計算するとしたら，演算ルーチンはおそらく数十行以上のものになるで 
しようし，バグの温床になるのは明白です 4 )。 


ただし，安易に引き算で計算できるかといえばそうではありません。先ほど引 
き算1つで求まると述べたのは，あくまでもで time 』 型を long 型として 
定義しているからにすぎないからです。もし time . t 型が構造体で定義されてい 
るような処理系では，問題となるでしょう。事実 AiVSJC では，型をどの 
ように表現するかについては定義していません。 


ですから， 47 V 57 C に準拠した行儀のよい，移ネ直性の高いプログラムを書くた 
めにも ， diff time 関数を使うべきです。 LIBC では, difftime 関数は引き算に 
変換されるマクロとして定義されていますから，速度的にも差はありません。む 
しろソースの移植性を重視すべきです。 


4) 加えていうならば，頭痛 
薬も必要でしょう。 


List 2-7 #2つの時間の差 


1 ： /* 

2: ** difftime.c: 

3: ** 1992 年 10 月 3 日 5 時 17 分 30 秒と 

4: ** 1993 年 1 月 15 日 8 時 30 分 0 秒の差を求める 

5: */ 

6 : # include <time.h> 

7: 

8 : double getDifference 、 void) 

9: { 

10: time_t cl,c2; 

11: struct tm tl,t2; 

12 : 

13 : tl.tm_sec = 30; 

14: tl.tm_min =17; 

15: t1.tm_hour = 5; 

16: t1.tm_mday =3; 

IT : tl.tm_mon = 9; 

18: tl.tm_year = 92; 

19: tl.tm_isdst =-1; 

20 : 

21: cl=mktime (&tl); 

22 : c2 = mktime (&t2); 

23: return difftime (c2, cl); 

24: > 


t2.tm_sec =0; 
t2.tm_min = 30; 
t2.tm_hour = 8; 
t2.tm_mday =15; 
t2.tm_mon = 0; 
t2.tm_year = 93; 
t2.tm_isdst =-1; 


/* 秒 */ 

/* 分 */ 

/* 時 */ 

/* 日*/ 

/* 月 -1 */ 

/* 年 -1900 */ 

/* 夏時間を考慮 */ 
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5) 日本ではサマータイム制 
などと呼ばれることもあ 
ります。 


❖協定世界時 


時間には，地域時間と協定世界時の2通りの表現方法があります。本セクシヨ 
ンでは，そのうちの協定世界時について解説します。 


♦ 協定世界時とは 


協定世界時はいくつかある世界時のうち 


の1つで，セシウム原子の放射から算出 


された原子時に対して，閏秒などの修正を加えて地球の自転に合致させたもので 
す。英語では Coordinated Universal Time (略称 UTC ) といい，1925年1月1日 
からグリニッジ標準時 （GreemWch Mean Time 略称 GMT ) に代わって用いられて 
います。 


❖ 地域時間 


前セクシヨンで協定世界時について解説しました。ここではもう一方の表現方 
法である，地域時間について解説します。 


地域時間とは，協定世界時に対して時間 
帯（タイムゾーン）による時差を補正した 
もので，いわゆる日本時間がこれにあたります。日本は+9時間のタイムゾーン 
に属しており，地域時間は協定世界時より9時間進んでいることになります。 

また，地域時間は時差の補正だけではなく，国ごと，あるいは地域ごとに制 
定された夏時間などの補正が適用されることがあります。今のところ，日本で 
は採用されていませんが，アメリカなどでは夏時間 (Daylight Saving Time :略 
称 DST ) 5 ) を採用しています。 

これは1年のうちのある期間だけ時間をずらし，季節によって異なる日の長さ 
を有効に利用しようというもので，1時間ほど時間を進めるのが通例のようです。 


♦ 地域時間とは 


地域時間の見分けかた 


コンピュータが協定世界時から地域時間 
を計算するときに必要な情報は，最低限 
必要なもの，あってもなくてもいいものの両方を含めると，およそ次のようにな 
ります。 


• 協定世界時からの時差 
• 平常時の時間帯名（たとえば日本は JST ) 
• 夏時間の実施スケジュール 
• 夏時間の実施期間中の時差 
• 夏時間の実施期間中の時間帯名 
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これらの情報から，適切に地域時間を計算しなくてはならない点ではいずれの 
処理系も同じですが，その情報の取得方法という側面からは処理系ごとに異なつ 
ているようです。たとえば UNIX では，大別して2種類あるように見うけられ 
ます。 


1. 環境変数 TZ から地域時間名を取得して地域時間データベースを検索 

たとえば ソニーの NEWS-OS はこの方法をサポートしています。日本で使 
うならば， TZ=Japan などとします。 

2. 環境変数 TZ にすベての情報をつめ込む 

この方法は POS 7 Z .2 で規定されており，上記のすべての事項について記述 
できるようになっています。たとえば日本で使うならば， TZ = JST -9 などと 
します。 


UNIX では血筋でしょうか 6 ),こういった地域時間への対応がなされているも 
のがほとんどですが，バソコン上の MS — DOS や Human 68 k などは地域時間 
しか考えていないものが多いようです。 

では上述した pas / x .2 スタイルのタイムゾーン処理をサポートしていま 
すが，こういった Human 68 k の仕様上の問題で，どうしても正確な計算ができ 
ません。これは MS - DOS にしても同じなのですが， OS を通して扱う時間がす 
ベて地域時間であることです。 UNIX では OS で扱う時間は暦時間，つまり協定 
世界時ですから，世界中どこでもタイムゾーンの設定さえすれば使用できます。 
しかし， 0 S が地域時間しか扱えないとなると，時間帯をまたがった場合にいろ 
いろな問題が生じてきます。 

たとえば，ある人が日本で仕事をし， “ FILE . 1” を作成したとします。このファ 
イルは1993年3月1日正午，つまり協定世界時の1993年3月1日午前3時に 
作成したもので，それ以降は何もしていません。 


6) アメリカなどは同じ国の 
なかで，いくつもの時間 
帯に分割されていますか 
ら必然的にそうなってき 
たのではないでしようか。 


A:\> DIR 

ドライブ A: のボリュームラべルは HUMAN 
デイレクトリは A:\ 

BIN <DIR> 93-03-01 08:30:00 

FILE 1 5000 93-03-01 12:00:00 

FILE 2 4872 93-01-01 14:23:00 

4 個のファイルがあります。 

20259568バイトが使用可能です。 


次に，その人は協定世界時からの時差が2時間の国へ，そのディスクをもって 
いきます。その国で同じようにしてディスクの中身を見ると，おそらく次の画面 
のように表示されるでしょう。なぜならばコンピュータの時間設定が， OS 上で 
その国の時間に合わされ てい るからです。 
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A:\> DIR 

ドライブ A: のボリュー•ムラべルは HUMAN 
デイレクトリは A:\ 


BIN <DIR> 93-03-01 08:30:00 

FILE 1 5000 93-03-01 12:00:00 

FILE 2 4872 93-01-01 14:23:00 

4 個のファイルがあります。 

20259568バイトが使用可能です。 


つまり，時間がすべて地域時間で記録されているために，どこへもっていって 
も同じ時間になってしまうのです。考えてみればこの時間帯+2時間の国で，1993 
年3月1日正午に作成したと表示されているわけですから， “FILE.1” は協定世 
界時の1993年3月1日午前10時に作成されたということになってしまいます。 
ここで7時間ものずれが生じてしまい，事実が失われてしまいました。 

しかし正しく協定世界時と地域時間を使い分ける OS さえ使っていれば，この 
ような事態にはなりません。今の例と同じようなことを， UNIX 上で実験して 
みましょう。まず，日本で見た結果。 


7.is -IF 
total 2 

drwxr-xr-x 2 mura 
-rw-r--r--1 mura 
-rw-r — r--1 mura 


512 Mar 108:30 BIN/ 
5000 Mar 112:00 FILE.l 
4872 Jan 114:23 FILE.2 


次に時差 2 時間の国で見た結果。もちろん正しくタイムゾーンを設定しています。 


% Is -IF 
total 2 

drwxr-xr-x 2 mura 
-rw-r--r 一一 1 mura 
-rw-r —— r —— 1 mura 


512 Mar 101:30 BIN/ 
5000 Mar 105:00 FILE.l 
4872 Jan 107:23 FILE.2 


正しく時間が表示されました。一見すると時間が変わってしまったように思いま 
すが，協定世界時に直してみれば，同じ時間を表していることに気づくはずです。 
ここが地域時間の重要な部分です。 


地域時間を基準としてはならない 


♦ L/BC での制限事項 


L/ 及 C では，可能なかぎり正確に協定世 
界時と地域時間を区別して扱うように努 
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1. 日本で使うこと 

Human 68 k がシステムクロックを地域時間でしか扱えない以上，それを協 
定世界時に逆変換するには仮定が必要です。つまり，「今使っているのは日本 
であり，システムクロックは日本時間を表している」ということです 。 LIBC 
は， Human 68 k から得た現在時刻から協定世界時を求めるために，つねに 
9時間を引いています。しかし日本以外，正確には+9時間の時間帯外では, 
先ほど述べたような問題が残っています。 

2. フルデコード tzset 関数を使うこと 

UBC には,タイムゾーンを計算するための tzset 関数が2種類あります。 
1つは簡易型で，日本時間しか扱えず夏時間についても考慮しません。もう 
1つは完全型で， P 0 SIX . 1 で規定されている環境変数 TZ の設定をすべてサ 
ポートしており，将来日本で夏時間が導入されても，環境変数の設定だけで 
正しく時間を扱うことができます。ただし，完全型は実行コストがかかるう 
えに実行ファイルのサイズが大きくなってしまいますから，デフォルトでは 
簡易版が使用されるようになっています。もし完全型を使用したければ，コ 
ンパイラに- ltz を指定するか，リンカに直接 libtz . a を指定するようにし 
てください。 


A:\> gcc -□]lkan.c -ltz 


❖詳細時間 


ここまでで暦時間/協定世界時/地域時間について解説してきました。おおまか 
な概念はつかめたでしょうか。それでは，これらの時間を実際に扱ってみること 
にしましょう。 


♦ 詳細時間とは 


暦時間がいわば，計算向きの表現方法で 
あるのに対して，詳細時間は年月日/時 


分秒を独立して扱うことのできる人間向きの表現方法といえます。詳細時間は， 
tm 構造体で表現されています。 tm 構造体は，それぞれ Table 2-17 のようなメン 
バで構成されています。 


この tm 構造体のメンバのうち tm _ wday ， 
tm _ yday については，先ほど説明した 
mktime 関数 (List 2-6 参照）を使って， tm 構造体から time — t 型に逆変換すると 
きには設定しなくてもかまいません。なぜならば，これらの構造体メンバはほか 
の値から計算できるからです。逆にいえば，これらの値を求めるために mktime 
関数を用いることができます （List 2-8 参照)。 


♦ tm 構造体の再計算 


67 










Table 2-17 • tm 構造体の内容 


メ ンバ名 範囲 解説 


int tm_sec 

0 < x < 59 

int tm_min 

0 < x < 59 

int tmJiour 

0 < rr < 23 

int tm_mday 

1 < a; < 31 

int tm_mon 

0 < a; < 11 

int tm_year 

0 < x 

int tm_wday 

0<x<6 

int tm_yday 

0 < x < 365 

int tm_isdst 

0 or 1 

char *tm_zone 


long tm gmtoff 



秒 

分 

時 

0 

月から1を引いたもの 
年から1900を引いたもの 
曜口（日曜日を0とする） 

年の通算日 
夏時間の期間中は1 
地域時間名 （JST など） 
協定世界時と地域時間の差（秒) 


List 2-8# mktime 関数の別の使い方 


2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 
ir, 
16 


17 

18 
L9 
20 
21 
22 


/* 

** mktime2.c : 

** 1985 年 12 月 14 日は何曜日だったかを求める。もちろんもっと 

** 簡単な方法があるが，思い出せなければこういう方法でも可 
** 能ということである 
*/ 

# include <time.h> 


int getWeekDay 、 void) 
struct tm t; 


t.tm_sec 

= 

0; 

/* 

秒 

本 / 

t.tm_min 

= 

0; 

/* 

分 

本 / 

t.tm_hour 

= 

0; 

/* 

時 

*/ 

t.tm_mday 

= 

14; 

/* 

日 

*/ 

* ~tni mon 

= 

11; 

/* 

月 

- 1 */ 

t.tm_yeax 

= 

85; 

/* 

年 

-1900 */ 

t.tm_isdst 

= 

-1; 

/* 夏時間を考慮 */ 

mktime (&t); 
return t.tm_wday; 

/* 

mktime が足りない部分を補う */ 


♦ 協定世界時と地域時間 


協定世界時や地域時間を求めるには， 
gmtime 関数や localtime 関数を使いま 


すが，どちらも結果として，この tm 構造体へのポインタを返してきます。ただ 


し，注意点があります。それはこれらの関数，つまり gmtime 関数と localtime 
関数の返してくるポインタが関数内部の静的領域を指しているということ，要す 
るに，関数をもう一度呼び出すと前の値が消えてしまうということです。 List 2-9 


に正しい例と失敗例を示してみます。 


tm 構造体の内容は上書きされる 
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List 2-9 • gmtime 関数， localtime 関数の使い方 


2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 
1 !) 
50 


/* 

本本 localtime.c: 

** 現在の協定世界時と地域時間を調べる悪い例 

*/ 

#include <time.h> 


void printTimel (void) 

{ 

time_t now; 
struct tm *tgmt; 
struct tm 本 tloc; 

/* 

** gmtime の結果を參照する前に localtime で結果を 
** 上書きしてしまっている。どちらも JST を表示する 
*/ 

now = time (NULL) ; 
tgmt = gmtime (&now); 
tloc =localtime (&now); 

printf ("UTC time is 7,02d: # /,02d ： 7.02d\n", 

tgmt - >tm_hour, tgmt->tm_min, tgmt->tm_sec); 

printf ("JST time is °/,02d:7,02d: # /,02d\n", 

tloc->tm_hour, tloc->tm_min, tloc->tm_sec); 


/* 

** 現在の協定世界時と地域時間を調べるよい例 
*/ 

void printTimel (void) 

{ 

time_t now; 
struct tm *tgmt; 
struct tm *tloc; 


now = time (NULL); 


/* 

** tm 構造体のコピーを行いたくないならば，その場その場で 
** 値を参照すること 
*/ 

tgmt = gmtime (&now; ; 

printf ("UTC time is y D 02d:%02d:%02d\n " ， 

tgmt->tm_hour, tgmt->tm_min, tgmt->tm_sec); 


tloc =localtime (&now); 

printf ("JST time is # / e 02d ： 7,02d: # /,02d\n", 

tloc->tm_hour, tloc->tm_min, tloc->tm_sec); 


} 


文字列に直す-その 1 


詳細時間を文字列に直すにはいくつかの 
方法があります。そのなかで最も簡単な 
のは， asctime 関数と ctime 関数を使う方法です 0 これらの関数は，与えられ 
た tm 構造体へのボインタから，決められたフォーマットで文字列に直してくれ 
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ます。ただし，どちらも指定するのは協定世界時でなければいけません。それを 
asctime 関数は協定世界時で， ctime 関数は地域時間で表現します 0 

asctime 関数， ctime 関数には協定世界時を与える 


List 2-10 •asctime 関数と ctime 関数 


1： /* 

2 : ** jikan.c: 

3: ** 現在時刻を求め，それを協定世界時と地域時間で表示する 

4: */ 

5 : #include <stdio.h> 

6 : #include ぐ time.h 〉 

7: 

8: int main (void) 

9: { 

10: time_t now; 

11: struct tm *tmptr; 

12 : 

13: now = time (NULL); /* 現在時刻を得て */ 

14: tmptr = gmtime (&now) ; /* 協定世界時の詳細時間に変換する */ 

15: 

16: fputs (asctime (tmptr), stdout); /* 協定世界時を表示 */ 

17: fputs (ctime (tmptr) , stdout) ; /* 地域時間を表示 */ 

18: 

19 : return 0; 

20 : > 


このプログラムを実行させると，次のような結果を出力します。 


A:\> jikan 

Tue Mar 123:24:54 1993 
Tue Mar 2 08:24:54 1993 
A: \> 


決まったフォーマットでよいならば，先 
ほどの asctime 関数や ctime 関数が便 
利ですが，もちろん自分の好きなフォーマットで日付を出力する方法もあります。 
strftime 関数を使うと，詳細時間を自分の好きなように加工/出力することがで 
きます。ただし， strftime 関数は詳細時間を文字列に変換して加工するだけな 
ので，協定世界時と地域時間の変換はあらかじめ施しておく必要があります。 

strftime 関数を呼ぶ前に地域時間に変換すべし 


♦ 文字列に直す-その2- 


詳しい フォーマットは Vol .2 の マニュアルを 参照していただくとして，いくつ 
か変わった フォーマッ トを定義して表示させてみましょう （List 2-11 参照)。 すべ 
て現在時刻を表示しています。 
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List 2-11• strftime 関数の使い方 


1: /* 

2 : ** hyouji.c : 

3: ** strftime 関数を使った表示例 

4: */ 

〇 : #include <stdio.h> 

6 : #include <time.h> 

7: 

8 : mt main (void) 

9: { 

10: time_t now; 

丄丄： struct tm *tmptr; 

12: char buffer[256]; 

13: 

14: now = time (NULL) ; /* 現在時刻を得る */ 

15: tmptr =localtime (&now); /* 地域の詳細時間に変換する */ 

16: 

17 : /* 例 1 */ 

18: strftime (buffer, sizeof buffer, "%x %X # /,Z", tmptr); 

19: puts (buffer); 

20 : 

21: /* 例 2 本 / 

22: strftime (buffer, sizeof buffer, " # / 0 A ®/,B B /»d # / 0 Y ( # /,p # /,I : # / 0 M : # /»S) " , tmptr); 

23: puts (buffer); 

24: 

25: /* 例 3 */ 

26: strftime (buffer, sizeof buffer, "7 0 a %d/%m/%y [%j] " , tmptr); 

27 : puts (buffer); 

28: 

29 : return 0; 

30: } 


上記のプログラムをコンパイルし実行させると，画面には次のように表示され 
ます。 


A: \> hyouii 

03/02/93 14:02:20 JST 

Tuesday March 021993 (PM 02:02:20) 

Tue 02/03/93 [061] 

A:\> 


71 









ライブラリー第 1 部 



❖ ヒープ領域の実際 


ヒープ領域とは， c 言語で作成されたプログラムが自由に利用できるメモリ領 
域のことです。このメモリ領域からは， malloc 関数によって指定したサイズのメ 
モリブロックを切り出したり，逆に: free 関数によって戻したりすることができ 
ます。本セクションでは，ヒープ領域の取り扱いについて解説します。 


l ) Human 68 k のメモリ 
ブ□ックを取得したり解 
放するのは DOS コール 
で行います。 


よく勘違いされやすいのですが，ヒープ 
領域は Human 68 k が管理しているメモ 
リ領域ではありません。 Human 68 k がプログラムに対して与えているメモリブ 
ロックのなかの一部分で， C 言語のライブラリが管理するメモリ領域です。この 
関係を図に示すと， Fig . 2-2， Fig . 2-3 のようになります。システム全体のメモ 
リ空間に対して， Fig . 2-2 は Human 68 k が管理している 1 )メモリブロックの並 
び方を図示したものであり， Fig . 2-3 はそのなかの「現在実行中のプログラム」 
の部分をさらに拡大したものです。 


♦ ヒープ領域とは何か 


ヒープ領域は実行中のプログラムの一部である 


ヒープ領域は有限ですから， malloc 関 
数によってメモリブロックを確保してい 
くと，そのうち空き領域がなくなってしまいます。このとき， C ライブラリは 
ヒープ領域を sbrk 関数によって拡張しようとし， sbrk 関数は Human 68 k に対 
して自分のプログラムが占めている Human 68 k のメモリブロックを大きくして 
くれるように DOS コール SETBL 0 CK を発行します。 

もし，ここで Fig . 2-2 中の「プロセスの後ろの空き領域」に余裕があれば， 
Human 68 k はこの要求を認め，プログラムが占めているメモリブロックを拡張 
します。それによって， Fig . 2-3 中のヒープ領域のサイズも大きくなりますから， 
新たに malloc 関数によって割り当てられる領域が増え，万事めでたしというこ 
とになります。 

しかし「プロセスの後ろの空き領域」がなく，すぐ後ろに Human 68 k が管理 
する別のメモリブロックがあったり，物理メモリー杯まで使い切ってしまうと， 


♦ ヒープ領域の拡張 
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システムワーク 

$000000 

Human 68 k 

$006800 

デバイスドライバなど 


常駐プログラムなど 




Fig.2-2« システム全体と Human68k の管理するメモリの関係 


メモリ管理ブロック 


プロセス管理ブロック 


プログラム領域 


データ領域（初期値なし） 


データ領域（初期値あり） 


スタック令頁域 


ヒープ領域 


ライブラリが管理する領域 


Fig.2-3« プログラム内部のヒープ領域の位置 
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ライブラリー第 1 部 


2) 変数 errno に設定され 
るエラー番号は EN 0 MEM 
です0 


Human 68 k はプログラムが占めているメモリブロックを拡張することができま 
せんから，連鎖的に malloc 関数も新しいメモリブロックの割り当てができなく 
なります。これが C 言語のライブラリでいうところの「メモリ不足」 2 )です。 

「メモリが分断している状態」のことをいう 


3) L/fiCT (i Boundary 
Tag Method という 
動的メモリ管理方法を 
ベースとして，少し改良 
を加えたものを使用して 
います。 


たとえば，あるプログラムから system 関数によって常駐型のソフトウヱアな 
どを子プロセスとして実行させると，場合によっては現在実行中のプロセスの後 
ろにその常駐ソフトウヱアが居座ってしまい，上述したような現象になることが 
あります。よく「空きメモリが 2 M バイトもあるのに空きメモリがなくなった」 
という話を聞きますが，こうしたことが，その原因であることも多いようです。 

上記のような問題が起きないヒープ管理 
の方法もあります。もちろん物理メモリ 
を全部使い切ってしまった場合はだめですが，上述したメモリブロックの分断に 
よるメモリ不足程度ならば，解決するのは比較的簡単です。ヒープ領域の拡張が 
できなくなった段階で Human 68 k から新しいメモリブロックを割り当ててもら 
い，そこに第2，第3のヒープ領域を構築すればよいのです。確かに管理する側 
のライブラリから見ると，ヒープ領域が複数存在し，しかもメモリ空間のなかで 
飛び飛びになってしまうために，非常にやりにくくなりますが，アプリケーショ 
ン側から見るかぎりはその違いがわからないので，有用な方法だと考えられます。 

しかし残念ながら， ZJ 万 C のヒープ領域管理ルーチン 3 )は同時に1 つの ヒープ 
領域しか扱えませんから，このような芸当はできません。複数のヒープ領域を考 
えるときに， sbrk 関数や brk 関数の関数の仕様を満足するにはどのようにする 
か，その解決方法がまだ煮つまっていないためです。将来，バージョンアップに 
よってこのことが可能になることを祈ります。 


♦ 優れたヒープ領域管理-その 1- 


♦ 優れたヒープ領域管理-その2- 


一般に，ヒープ領域はメモリ不足が起こ 
るたびに自動的に拡張されていきますが， 


逆にメモリがあまっている状態になっても縮小されることはありません 。 GNU 
maiioc ライブラリなど，メモリに余裕が出た場合にヒープ領域を縮小するものも 
ありますが，このような優れたヒープ管理を行っているライブラリは小数派に属 
します。のヒープ管理ルーチンも含めて，むしろほかの大他数のライブラ 
リでは，一度拡張されたヒープ領域は縮小しません。 

ヒープ領域が縮小されないというのは，メモリ効率をひどく悪化させます。た 
とえばエディタについて考えてみましょう。最初に 1 M バイト近いファイルを編 
集しようとしてメモリに読み込むと，ヒープ領域はそれに合わせてかなり拡張さ 
れるはずです。この時点でエディタが占有しているメモリ領域は， 1 M バイトを 
はるかに越える大きさになるでしょう。しかし，その後ファイルの編集が終了し， 
そのファイルのデータを破棄したとしても，一度拡張されたヒープ領域は縮小さ 
れず，またプログラムが占有するメモリ領域も変化しません。本来，それだけの 
ヒープ領域を必要としていなくても，です。 
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前述した複数ヒープ領域の管理やヒープ領域の自動縮小などの課題が ， LIBC 
には残されています。おそらくは管理方法をかなり変更しないと，実現するのは 
難しいかもしれません。 


❖配列と動的メモリ確保 


まず最初に，配列と動的メモリ確保 （Dynamic Memory Allocation ) の違いか 
ら考えてみましよう。本質的には，どちらもメモリ上のある領域をアクセスするた 
めのものであり，大きな違いはないのですが，それぞれに長所/短所があります。 


|最初に，配列の長所から酬しましょぅ。 
_配列では宣言時に初期値が明確に決定さ 


れます。つまり，配列に対して初期化要素を与えればその初期化要素が初期値に 


なり，なければ0が初期値となります。そして C 言語で規定される変数のスコー 


プにしたがって管理されるため，メモリ領域の確保/解放などに気を使う必要が 
ありません。また配列は宣言することも，扱うことも非常に簡単です。特に，多 
次元（2, 3,…， n 次元） の データを扱うには，配列を使う のがい ちばん簡単です。 
たとえば List 2-12 がその一例です。 


List 2-12 •配列の長所 


1 ： /* 

2 : 木本 array.c : 

3: ** 配列は初期化要素がすべて 0 である。また多次元のデータに容易に 

4: ** アクセスできる 

5: */ 

6 : int array [50] [50] ; /* 2 次元配列*/ 

7: 

8: void InitializeArray ^void) 

9: { 

10: int i; 

11 : 

12 : /* 

13: ** 配列の座標 (n,n) の値を n にする。それ以外の座標の値は暗黙の 

14: ** うちに 0 であると期待してもかまわない。また， 2 次元配列へのァクセ 

15: ** スも array [i] [i] のように非常に簡単である 

16: */ 

17: for (i = 0; i < 50; i++) 

18: array[i][i] = i; 

19: } 


配列の短所 


配列のサイズが宣言時に決定されてしま 
うということは，逆にいえば後から変更 
することができないということです。たとえば要素数が1000の配列を宣言した 
とすると，実際に必要な要素数が100であれば残り900はムダになるし，2000 
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であれば1000も足りません。つまり固定サイズの配列は，状況に応じて最適な 
サイズに調整することができないのです。このため，えてして配列の要素数がプ 
ログ ラムの 機能の制限を生み出すことになります。たとえば List 2-13 がその一 
例です。 


List 2-l:U 配列の短所 


1 ：卜 

2 :本本 array_str.c: 

3: ** 配列を用いると，状況の変化に対して柔軟に対処すること 

4: ** ができない。文字列の入力を例にとると .. •• 

5: */ 

6 : #include <stdio.h> 

7: 

8: char *getString ^void) 

9: { 

10: static char buffer [256]; /* 256 バイトの文字配列 */ 

11 : 

12 : /* 

13: ** fgets 関数は配列を用いるので，この場合 256 バイトを 

14: ** 越える文字列を処理することができない 

15: */ 

16: return fgets (buffer, sizeof bufier, stdm); 

17: > 


次に，動的メモリ確保の長所について説 
明しましょう。必要に応じて必要なサイ 
ズのメモリ領域を確保することができ，しかもそれを配列のように自由に扱うこ 
とができます。また，いったん領域確保した後でも，そのサイズを変更すること 
ができます。したがって，状況に応じて柔軟に対処できるプログラムを作成する 
ことができます。 

たとえば次の List 2-14 のようなプログラムを，配列を用いて作成したとしま 
す。大きなファイルも読み込めるようにと， 1 M バイトの配列を取ってしまうと， 
10 K バイト程度の小さなファイルでも 1 M バイトのメモリが必要になる反面， 2 M 
バイトのファイルを読み込むことはできません。 


♦ 動的メモリ確保の長所 


List 2-11 •動的メモリ確保の長所 


1 ： /* 

2 : ** malloc.c: 

3: ** 動的メモリ確保は状況に応じて領域のサイズを動的に変更すること 

4: ** ができるのが強み。たとえば次の例は，ファイルの中身をメモリに 

5: ** 読み込む処理だが，ファイルの大きさによって読み込み領域のサイ 

6: ** ズを決定している 

7: */ 

8 : # include <stdio.h> 

9: # include く stdlib.h 〉 

10: # include <svs/stat.h> 

11:#include <unistd.h> 

12: #include <fcntl.h> 

13: 

14: unsigned char *f ile_contents; /* ファイルの中身を読み込む領域 */ 
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15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 


void readFileIntoMemory (char *file_name) 

{ 

int fd; 

struct stat st; 


/* ファイルのサイズを調べる*/ 
if (stat (&st, file.name) < 0) { 

fprintf (stderr, "7.s が見つかりません , f ile.name); 

exit ⑴； 

} 

/* メモリを確保する。サイズは st.st_size */ 

file 一 contents = ^ unsigned char *) malloc (st.st.size); 

if (file_contents == NULL) { 

fprintf (stderr, "メモリ が足りません \n") ; 
exit ⑴； 

> 

/* ファイルをオーブンする*/ 

if ((fd = open (file.name, 0_RD0NLY I O.BINARY)) == NULL) { 
fprintf (stderr, ,,# / # s が才 ープン できません \n" , f ile.name); 
exit ⑴； 

> 

/* 読み込んで ...*/ 

read (td, file_contents, st.st.size); 

/* クローズ */ 
close (fd); 


動的メモリ確保の場合，実行時にメモリが足りなくなると malloc 関数がエラー 
を返すため「安心して使うことができない」のではないか，という不安感もあり 
ます。確かに配列は実行さえできれば，途中でメモリが足りなくなるというよう 
なことはありません。その意味ではより安心かもしれませんが，結局は，本当に 
「メモリが足りない」のであれば，配列を用いたプログラムは実行できません。 

動的メモリ確保の短所は，実は，かなり 
あります。それではその最も大きな短所 
(考え方にもよるかもしれません）を，2つあげてみましょう。 

1. 自分でメモリ管理をしなければならない 

配列は extern 型， static 型あるいは auto 型にしろ， C 言語で定義されて 
いる変数のスコープにしたがって管理されますが， malloc 関数などを用い 
て動的に確保したメモリ領域は自分で管理しなくてはなりません。メモリが 
必要になった時点で「自分で」確保しなければならないし，不要になった時 
点で「自分で」解放しなくてはなりません。たとえば List 2-15 を見てくだ 
さい。この例では （ A ) の時点で （34 行目），もはや変数 new - area が指す領域 
は必要なくなっているので解放する必要があります。このことを忘れている 
ため，このルーチンは呼び出されるたびにメモリのムダ使いをします。 


♦ 動的メモリ確保の短所 
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List 2-15 •動的メモリ確保の短所 


1 : /* 

2 : ** free_err.c: 

3: ** 次のルーチンでは確保したメモリ領域が不要になったときに解放する 

4: ** ことを忘れている。したがって，ルーチンが呼ばれるたびに無限に 

5: ** メモリを消費している 

6 : */ 

7 : # include <stdlib.h> 

8 : # include <stdio.h> 

9 : # include <string.h> 

10 : 

11:void concatCall (const char *stringl, const char *string2) 

12 : { 

13: int lengthl,length2; 

14: char *new_area; 

15: 

16: /* stringl と string2 の長さを求める*/ 

17: lengthl=strlen (stringl); 

18: length2 = strlen (string2); 

19: 

20: /* 2 つの文字列を合わせたサイズを確保する*/ 

21: new_area = (char *) malloc (lengthl + length2 + 1); 

22 : if (new_cLrea == NULL) { 

23: fprintf (stderr, "メモリが足りません \n"); 

24: exit (1); 

25: > 

26: 

27: /* 2 つの文字列をつなげる*/ 

28: strcpy (new_area, stringl); 

29 : strcat (new_area, string2); 

30: 

31: /* つなげた文字列を表示する*/ 

32 : puts (new_area) ; 

33: 

34: /* 

35: ** (A) 本来ならば，ここで free (new_area) しなければなら 

36: ** ないが忘れている 

37: */ 

38: > 


4) ヒープ領域の管理アルゴ 
リズムや状況によります。 

5) IC ’ では，メモリのフラグ 
メ ンテーシヨンが 増大す 
ると棰端に遅くなります。 


2. 実行コストがかかる 

配列とは異なり，動的メモリ確保は必要になった時点で空いているメモリ領 
域を探してこなくてはなりません。そのため，実行時にそれなりの実行コス 
卜 4 )がかかります。ほんの少しの回数ならば負担にはなりませんが，数百回， 
数千回，数万回実行されたら無視できなくなります 5 ^ 

配列と動的メモリ確保には，それぞれに 
以上のような長所/短所が存在していま 
す。メモリ領域（配列といってもよいでしょう）を必要とするすべての場所で，作 
成するプログラムの性格/用途などを考えて，どちらか適した方法を選択する必 
要があります。一般には，次のような判断基準が考えられます。 


♦ 両者の選択 


• 必要とする領域のサイズが固定ならば配列を利用する 
• 実行コストを抑え，高速に実行したいならば配列を利用する 
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• 必要とする領域のサイズが可変あるいは予測できないならば，動的メモリ確 
保を使用する 


•プログラムの実行に制限事項があってもよければ配列でもよい 
• プログラムの実行に制限事項があってはいけないならば，動的メモリ確保を 
使用する 

• 必要とする領域そのものの必要数が可変あるいは予測できなければ，動的メ 
モリ確保を使用する 

これらの判断基準は不確実ですから，実際に試してみて，考えるのがいちば 
んです。ところで，配列の長所も動的メモリ確保の長所も，そのどちらも合わせ 
もった方法があります。 alloca 関数は，これら2つの選択肢以外に加えてみて 
もよいかもしれません。詳しくは後述する「スタックからメモリを確保」 （ P .84) 
を参照してください。 


プログラムに制限をつけるのは好ましくない 


❖ ヒープ領域の使い方 


以上で，ヒープ領域とそれを用いた動的メモリ確保について詳しく見てきまし 
た。本セクションでは，それらを実際に用いる方法について説明していきます。 


ヒープ領域からメモリ領域を確保する 

♦ メモリブロックを確保する 

_ためには， malloc 関数を使用します。 

malloc 関数は要求されたサイズのメモリ領域をヒープ領域から割り当て，その 
領域へのポインタを void * 型で返します 6 )。 

L / J 5 C ではこの ポイン タはすべて ロング ワードデータ境界，つまり MC 68020以 
上の MPU にとって最もきびしいアラインメントに調整されます。これは， C 言 
語で使用されるいかなるデータ型のボイ ンタ にでもキャストすることができ，し 
かも高速にアクセスできることを保証しなければならないからです。 

Fig . 2-4 を見てください。この図ではアドレス$200000からバイトデータ，ワー 
ドデータ， ロング ワードデータを並べたようすを図示しています。 MC 68000では 
バイトデータはどんな位置からも読み出すことができますが，ワードデータ/口 


6 )古い C 言語では void * 
型の代わりに ， char * 
型がよく用いられていま 


した。 



+0 

+1 

+2 

+3 

$200000 

BYTE 

BYTE 

BYTE 

BYTE 

$200004 

WORD 

WORD 

$200008 


LONG 

WORD 



Fig .2-4 • MC 68000 のアラインメント 
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ングワード データ は偶数アドレスからしか読み出すことができません。この制限 
は MC 68020以上の MPU ではなくなりましたが，奇数アドレスからのワードデー 
夕読み出しは，偶数アドレスからの読み出しに比べると非常に時間がかかるので， 
実際にはほとんど使われません。また MC 68020以上では，同様に奇数ワードアド 
レスからのロングワードデータの読み出しに非常に時間がかかります。 

また malloc 関数は，必要なメモリブロックが得られないときは NULL を返しま 
す。正しく メモリブロックが得られたかどうか，必ずチヱックすることが必要で 
す (List 2-16 参照)。 

malloc 関数の戻り値は必ずチヱックすること 


List 2-16 •malloc 関数の正しい用法 


1 : /* 

2 : ** xmalloc.c : 

3: ** 次の関数 xmalloc はいろいろなプログラムでよく使われる。同様に, 

4: ** xrealloc も用意するなど，エラーチェックつきのヒープ関数を作成 

5: ** しておくと非常に便利である 

6 : ♦/ 

7: #include <stdio.h> 

8: #include <stdlib.h> 

9: 

10: void *xma 丄丄 oc (size_t size) 

11 ：{ 

12: void *ptr; 

13: 

14: /* エラーチェックつき */ 

15 : ptr = (void 木 ) malloc (size); 

16 : if (ptr == NULL) { 

1 ( : perror ("xmalloc"); 

18: exit (1); 

19: } 

20 : 

21: /* ptr を返す*/ 

22: return ptr; 

23: } 


そして非常に重要な注意点として, 


メモリブロックのサイズを越えてアクセスしてはならない 


ということがあります。たとえば，200バイト分として確保したメモリ領域に対 
して，200バイトを越えるデータを格納したりしないでください。まったく関係 
のないほかの データが 破壊されるばかりか，ヒープ領域の 管理 そのものが正常に 
実行できなくなる可能性があります。こうした場合，実際に問題となっている場 
所とは異なる場所に異常が現れるので，デバッグがやっかいになります。 

たとえば，確保したメモリ領域のサイズは普通把握しているものですが，ふと 
したことで，気づかないうちに（つまり想像していなかった状況で）このサイズ 
を越えてしまうことがあるものです。どうしても納得のいかないようなデータ破 
壊があった場合，別の場所を疑ってみるのも手かもしれません。たとえば ， List 
2-17 のようなことが起こっていませんか。 
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List 2-17• ヒープ領域の破壊 


1： /* 

2 : 本本 heap_corup.c: 

3: ** 知らず知らずヒープ領域を破壊してしまう例 

4: */ 

5 : # include <stdlib.h> 

6 : 

7: /* 与えられた要素数 size の 2 つの配列の各要素を足し合わせる */ 

8: void addTwoArrays (int *arrayl,int *array2, int size) 

9: { 

10 : int i; 

11 : 

12 : /* 

13: ** 次の i <= size は本当は i く size のまちがいである。この 

14: ** まちがいによって，配列の本当のサイズを 1 つオーバーして 

15: ** しまう。その結果，どこか別のデータが破壊される可能性が 

16: ** あるが，下のまちがいが原因だとはなかなか気づかない 

17: */ 

18: for (i = 0; i <= size; i++) 

19: arraylti] = arrayl[i] * 3 + array2[i]; 

20: } 


一度 malloc 関数によって確保されたメ 
モリブロックのサイズを変更するときに 
は， realloc 関数を使用します。ライブラリの実装方法にもよりますが ， LIBC 
では， realloc 関数が指定されたメモリブロックのサイズを望みのサイズに変更 
するとき，次の2つの方法を使います。 

1. 空きスペースを有効利用する 

malloc 関数は，普通指定されたサイズよりも少しだけ余裕を見てメモリブ 
ロックを確保します。ですから，2バイトのメモリ領域を確保したからといっ 
ても，実際に2バイトしかないとはかぎりません。事実， U 石 C では， すべ 
て16の倍数に調整されます。この性質を利用し，変更するサイズがこの余裕 
分でまかなえる範囲内ならば，管理上のサイズを変更するだけですみます。 
また変更したいメモリ領域の後ろに，空いているメモリ領域があれば，それ 
を用いることもできます。 

2. 別の場所に移動する 

どうしても簡単に変更できない場合， realloc 関数は指定されたサイズに見 
あう メモリ ブロックを別の場所に確保し，現在の メモリ 領域の内容をすべて 
コピーします。 

(2.) の場合， メモリ ブロックの中身は同じでも位置が変わってしまいます。 こ 
れまで使っていた メモ リブロックはすでに存在しませんから，元の位置を指すよ 
うなボインタがあれば，新しい位置を指すように変更しなければなりません。 


♦ メモリブロックのサイズ変更 
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7) すでに説明したとおり， 
Human 68 k の空きメ 
モリ容量は増えません0 


必要なくなったメモリブロック 7 )は ， free 
関数を用いて解放することができます。 
解放されたメモリはヒープ領域に空きメモリブロックとして戻され，後で malloc 
関数や realloc 関数によって再利用されます。 

いったん解放され，アプリケーションの手から離れたメモリブロックは内容が 
保証されません。解放された後のメモリブロックの中身にアクセスするようなプ 
ログラム（たとえば List 2-18 のようなプログラム）は，書かないようにしてくだ 
さい0 


♦ メモリブロックを解放する 


List 2-18* free 関数の誤った使い方 


1 : /* 

2 : ** 丄 ist 一 ; free.c: 

3: ** 線形リストに組み合わされたメモリブロックを解放する 

4: */ 

〇 : struct DList { 

6 : struct pList *next; /* 線形リストの次のブロックを指す*/ 

7: double x, y, z ; /* 3 次元座標*/ 

8： }； 

9: 

10: /* まちがい*/ 

11 : 

12: void freePomtListi ^struct pList *top) 

13: { 

14: /* 線形リストを先頭から順番に解放*/ 

15: for ( ; top; top = top->next) 

It): iree (top); 

17: 

18: /* 

19: ** top = top->next の部分は free (top) で top が指す メ 

20: ** モリブロックが解放された後で実行される。解放された 

21: ** メモリブロックである top をアクセスしてはならない 

22 : */ 

23: } 

24: 

25: /* 正しくは...*/ 

26: 

27: void freePomtList2 ^struct pList *top) 

28: { 

29 : struct pList *next; 

30: 

31: /* 線形リストを先頭から順番に解放*/ 

32: for ( ; top; top = next) { 

33: next = top->next; 

34 : free (top); 

35: > 

36: > 
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2.5. スタック領域 


❖スタック領域の使われ方 


GCC などを含め，一般の C 言語ではどのようにスタック領域を利用している 
のでしようか。スタック領域の詳しい説明にはいる前に，まず簡単におさらいし 
ておきます。 


♦ 引数の渡し方 


GCC 1 ) では，引数をスタックと呼ばれる 
領域に格納して，関数の呼び出しを行っ 
ています。細かいことを説明してもわかりにくいでしょうから，具体的に順を追っ 
て説明していきましょう。たとえば， char 型と char * 型の2つの引数をもつ関 
数 foo を呼び出すことを考えます。 foo 関数のプロトタイプは次のようになって 
います。 


i)c というよりは， c コン 
パイラによって生成され 
た実行ファイルです0 


List 2-19• foo 関数のプロトタイプ 


2 

3 

4 

5 

6 


extern void foo 、char letter, char ^message); 

void fatalError (void) 

{ 

h foo を呼び出す */ 

foo (’A、"Error message"); 


Fig . 2-5 を見てください。まず，呼び出し元の関数は引数を後ろからスタック 
上に格納していきます。最初は letter , 次に error ， そ して最後に foo 関数から戻 
るときの戻り先アドレスです。ここで注意することが1つあります。1バイトの 
データである char 型の引数が，4バイトの領域を占めているということです。 

引数は，構造を簡単にするためやアラインメント 2 )や効率化のために，たとえ 
1バイトのデータでも，ある程度の領域を使って格納されるているのが普通です。 
この最低八イト数は MPU の特性によるわけですが， X 68000 で使われている 
MC 68000や X 68030 で使われている MC 68030では4バイトデータ，つまり1 
ロングワードデータが最適とされています。 


2) MC68000 では，奇数アド 
レスからのワードデータ/ 
□ ングワードデータ読み 
出しはできません。 


char 型も short 型も1ロングワードデータで扱われる 


83 


















ライブラリー第 1 部 


3) 引数を捨てるとは，つま 
りスタックポインタの値 
に引数が占めていたバイ 
卜数を加算して，元に戻 
すということです。 


4) 実際には，スタックボイ 
ンタの値を調整している 
にすぎません。 


SP 


char 


SP+4 

SP 


char 


char 


SP+8 

SP+4 

SP 


char 


char 


戻り先 


Fig .2-5» スタックの動き 


SP 


int 


SP+8 

SP 


int 


double 


SP+12 

SP+4 

SP 


int 


double 


戻り先 


Fig .2-6 • double 型は 8 バイトを占める 


呼び出された foo 関数は，どこを見れば目的の引数を取り出せるかを知ってい 
ます。たとえばこの場合， wmr が現在のスタックポインタの位置から計算して 
+4バイトの位置から1ロングワードデータ，また message が-^ から1ロング 
ワードデータに納められていることがわかっています。このようにして，関数と 
関数との間で，引数のやりとりが成立するわけです。 

では foo 関数の処理が終わり，もはや引数が必要なくなるとどうなるでしょう 
か。 foo 関数はスタック上に記憶されている戻りアドレスへジャンプし，呼び出 
し元の関数へ戻ってきます。そして，呼び出し元の関数がスタックを調整して引 
数を捨てます' 

ちなみに4バイトを越えるようなデータを引数に渡すと，どうなるでしょう 
か。答えは「そのままスタックに格納する」です。引数の占める最低のバイト数 
は存在しますが，事実上，最大バイト数は存在しません。もし，256バイトにも 
なるような大きな構造体をポインタ渡し （Call by reference ) ではなく，値渡 
し (Call by value ) で渡すようにすれば，当然256バイトがまるごとスタック 
上に格納されることになります （ Fig . 2-6 参照)。 

このように関数の呼び出しにはスタッ 
クが用いられますが，このスタックから 
malloc 関数のように，任意のサイズのメモリを確保することもできます。その 
ためには， alloca 関数を使います。この関数は，ちょうど auto 型の変数と同じ 
感覚でメモリ領域を確保することができます。 

ですから， alloca 関数で確保されたメモリ領域は解放する必要がありません。 
このメモリ領域はスタック上にあるために，ほかの auto 型変数と同じように，現 
在のスコープから出ると自動的に解放されます 4 )。 


♦ スタックからメモリを確保 


alloca 関数で確保した領域は自動的に解放される 

GCC では可変長の auto 型配列を宣言できる機能が披張されていますが，こ 
れは，まさにこの alloca 関数の機能と同じものです 。 List 2-20 を可変長配列を 
使って書き直すと ， List 2-21 のようになります。 
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List 2-20• alloca 関数の使い方 


1 ：/* 

2 : * 2 3 * 5 * 7 ►氺 allocatest.c: 

3: ** 2 つの引数を連結して表示する 

4: */ 

D : #include <alloca.h> 

D : #include <stdio.h> 

7: 

8: void pnntConcat (const char *stringl,const char *string2) 
9: { 

10: int size; 

丄丄： char ^result; 

12 : 

13: /* 文字列の長さを計算*/ 

14: size = strlen (stringl) + strlen (string2) + 1; 

15: 

16: /* その長さの領域を確保*/ 

17: result = (char *) alloca (size); 

18: 

19: /* 文字列を連結*/ 

20: strcpy (result, stringl); 

21: strcat (result, string2); 

22 : 

23: /* 結果を表示する*/ 

24: puts (result); 

25: 

26: /* この関数を抜けると result のバッファは解放される*/ 

27: } 


List 2-21 •可変長配列の使い方 


1 : /* 

2 : ** vararrav.c : 

3: ** 2 つの引数を連結して表示する 

4: */ 

5 : # include <stdio.h> 

6 : 

7 : void printConeat (const char *stringl,const char *string2) 
8: { 

9: /* 文字列の長さを計算*/ 

10: char result[strlen (stringl) + strlen (string2) + 1]; 

11 : 

12: /* 文字列を連結*/ 

13: strcpy (result, stringl); 

14: strcat (result, string2); 

15: 

16: /* 結果を表示する*/ 

17 : puts (result); 

18: > 
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5) ヒープ領域は足りなくな 
ると，自動的に大きさが 
拡張されていきます。 


スタック領域はヒープ領域とは異なり， 
足りなくなったからといって自動的に大 
きさが披張されたりはしません 5 )。プログラムを起動したときに割り当てられた， 
一定サイズの領域を使い回すことしかできないのです。もしも，この領域をすべ 
て使い切ってしまったらどうなるでしょうか。答えは「スタックオーバーフロー」 
です。このスタック オーバーフロー という現象は，概念としては非常に単純明解 
なのですが，実際に発生したときには非常に見分けにくいものです。 

スタックオーバーフローが起こると，これまで説明したような引数や戻りアド 
レスが スタック領域をはみ出して格納されていきます。 Fig . 2-7 を見てください。 
L 你 C では起動時に，この図のようにスタック領域を割り付けて使うようにしてい 
ます。スタックオーバーフローが発生すると，結果としてスタック領域のすぐ隣 
りのデータ領域が破壊され，プログラム内部のグローバル変数などの値が予期し 
ない値になってしまいます。さらに破壊が進めば，データ領域どころかプログラ 
ム領域までが破壊され，プログラムはもはや実行できなくなってしまうでしょう。 

しかしプログラムが異常終了したり，暴走したりしたからといって，それがス 
タック オーバーフロー によって起こされたものなのかどうかは，一概にはわかり 
ません。単なるプログラムのバグなのかもしれません。また逆にいえば，スタッ 
ク オーバーフロー によって引き起こされたことなのに，それをバグだと思って， 
一所懸命にソースコードとにらめっこするはめになるかもしれません。 


♦ スタックオーバーフロー 


原因はスタックオーバーフローか，それともバグか 


この原因を調べるため， GCC では関数ごとにスタックオーバーフローをチェッ 
クするルーチンを付加して，スタックチェックを行うようにすることができます。 
このスタックチェックルーチンは，関数が呼び出されるごとに今のスタックボイ 
ンタの位置を調べ，それがスタック領域からはみ出していればエラーとして表示 
するものです。もこの機能をサポートしており，スタックオーバーフロー 
が発生すると，次のようなメッセージを表示して異常終了します。 


11 be : stack over flow 


メモリ管理ブロ ック 
プロセス管理ブロ ック 
プログラム 領域 
データ領域（初期値なし） 
データ領域（初期値あり） 
スタック領域 
ヒープ 領域 


Fig .2-7 • 万 C のメモリ構成 
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/* 

** hello.c: 

** このプログラムはスタックに 128K バイト必要とする 
*/ 

#mclude <stdio.h> 

int _stacksiz =128 *1024; /* バイト単位で指定すること */ 

int main (void) 

{ 

printf ("Hello world !!\n"); 
return 0; 


確かに余計な処理が関数ごとに加えられるわけですから，サイズも少々大きく 
なりますし，実行速度も犠牲になります。しかし，それらよりもスタックがオー 
バーフローし ないかどうかを チェッ クするほうが大切な場合には，この機能を活 
用してみてください。特に，デバッグ時に有効な機能ではないでしょうか。使用 
するには，次のように指定します （ buggy , c というファイル名とします)。 


A: \> gcc -fstack-check bugerv. c 


スタックサイズの指定 


このようなスタックオーバーフロー を引 
き起こさないためにも，プログラムには 
それに適したサイズのスタック領域を与えてやる必要があります。 L / BC はデフォ 
ルトで 32 K バイトのスタック領域をプログラムに割り当てていますが，もしもこ 
のサイズを変更したいならば，次のような方法でプログラムを作成してください。 

〇つねに指定したサイズのスタック領域を割り当てたい場合 

L /5 C は起動時に変数- stacksiz の値を見て，スタック領域の大きさを決定 
しています。ですから，自分のプログラム内でこの変数を再定義してやれば 
よいので す。たとえば，プログラムに 128 K バイト （131072 バイ ト） の スタッ 
ク領域を与えたいときは次のようにします。 


f ックサイズを指定する 


〇起動時に一時的にスタックサイズを変更したい場合 

ZJJ 5 C はコマンドラインから特殊なオプションを用いて，スタック 
領域のサイズを変更することができます。たとえば，を使って作成し 
たプログラム“ hello ” のスタックサイズを，一時的に 128 K バイトにして起 
動したい場合は次のようにします。オプションの次の数字は，スタック領域 
のバイト単位のサイズを表しています。なお，指定した“- s :” オプション 
は L / 及 C が取り込んでしまうので，プログラムには渡されません。 


567890123 

IX IX IX 
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A :\> hello -+-s :131072 


❖可変長引数 


可変長引数とは，数の決まっていない引数列のことをいいます。たとえば printf 
関数などは引数の数が決まっておらず，必要に応じて増えたり減ったりします。 
このような，あらかじめ引数の数やそのデータ型などが不明な場合は，どのよう 
に引数を取り扱えばよいのでしょうか。本セクションでは，これらの扱い方につ 
いて触れることにしましよう。 


6) 実現方法が反&«の関数 
宜首の方法に依存してお 
り， 4 iVS / C 時代にはそぐ 
わないものです。 


可変長引数を取り扱うインタフユイス 
として，は2つのインタフェイス， 
<stdarg.li 〉 と Cvarargs.h> をもっています 0 しかしく varargs .h> は ZiC & jR 時 
代の C 言語で使われていた方法であり，いささか古くさい方法ですので 6 )，こ 
こでは解説しません 0 その代わりに， A / VSJC •で規定されたく stdarg.h> インタ 
フェイスのほうを使うことにします。どちらのインタフェイスも基本的には同じ 
ものですから，暇があれば，く varargs.h> のほうも自分で解析してみるのもよ 
いかもしれません。 


♦ 可変長引数とは 


-1可変長引数を扱うには，まず可変長引数 

♦ 準備 

' _リストを求めなくてはなりません。可変 

長引数リストとは，スタック上の引数を順番に取り出していくためのボインタと 
考えてよいでしょう。事実，そのとおりです。わかりやすいように，再び図を使つ 
て考えてみましょう。一例として， printf 関数を取り上げます。 


List 2-23 •可変長引数をもつ関数 


1 : /* 

2: 本本 printf.c 

3: ** 可変長引数をとる関数を呼び出す 

4: */ 

5: extern int printf (const char *format,...); 

6 : 

7 : void foo (void) 

8: { 

9 : printf ("I am # /,s, and 7,d yeax(s) old.\n", "Michael",10); 

10： > 
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Fig . 2-8 を見てください。可変長の引数を取り出すには，まず SP + 8 の位置 
を求めなければならないことがおわかりでしょうか。この位置から後ろの部分 
を可変長引数リストと呼びます。 く stdarg.h 〉 インタフェイスでは，これを求め 

















Chapter 2 — L / fiC •プログラミング 


SP+12 

SP+8 

SP+4 

SP 


10 


"Michael" 


format 


戻り先 


ク可変長引数リストの先頭 
通常の引数リストの最後 


Fig .2-8. 可変長引数をもつ関数の呼び出しスタック 

るために va _ start マクロを使います。 va . start マクロは通常の引数リストの最 
後の引数の位置を求め 7 ),そこから可変長引数リストの先頭アドレスを求めます 
(List 2-24 参照)。ですから可変長引数を扱う関数は，最低でも1つの通常引数を 
もたなくてはなりません。これか^隹一の制限事項です。 

最低1つは普通の引数が必要である 


• va _ start を使って引数リストの先頭を求める 


1 ： /* 

2: ** vastart.c: 

3: ** 可変長引数リストの先頭アドレスを求める 

4: */ 

5 : # include <stdarg.h> 

6 : 

i : mt pnntf ^const char *iormat,...; 

8: { 

9 : va_list ap; /* 可変長引数リストを扱うポインタ型 */ 

10 : 

11: /* ap にアドレスが格納される */ 

12: va_start 、 ap, format; ; 

13: 

14: : 

15: : 

16: 

17: /* リストへのアクセスが終わるときには va.end */ 

18 : va_end 、 ap) ; 

19: > 


可変長引数リストが求められたところで， 
いよいよ引数を取り出すことにしましよ 
う。リストから必要な引数を取り出すには， va _ arg マクロを使います。このマク 
口に，引数リストへのポインタと取り出したい引数の型情報を与えてやります。 
先ほどの例に戻って考えてみましよう。たとえば ， char * 型の引数“ Michael ” と 
int 型の引数10を取り出すには ， List 2-25 のようにプログラミングします。 


♦ 引数を取り出す 


7) これは&演算子を使えば, 
^ format で計算できます。 
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SP+12 

10 

SP+12 

10 

— 変数 ap 

SP+8 

"Michael" 

—変数 ap SP+8 

SP+4 

"Michael" 


SP+4 

format 

format 


SP 

戻り先 

SP 

戻り先 



Fig . 2-9 • va_arg によるポインタの変化 


の使い方 


2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 
17 


/* 

** vaaxg.c : 

** 可変長引数リストからデータを取り出す 

*/ 

# include <stdarg.h> 


mt pnntx、const char ^format,...) 

{ 

char *axgl; 
int arg2; 
va_list ap; 


va.start (ap, format); 
argl=va_arg (ap, char *); 
arg2 = va_arg (ap, int); 
va_end (ap); 


/* ap を初期化 */ 

/* ap から char * 型の引数を取り出す */ 
/* ap から int 型の引数を取り出す */ 

/* 終わり */ 


8) たとえば， double 型の引 
数を float 型で取り出し 
たりしないでください。 


List 2-25 中では， va_arg マクロを2回呼び出していますが， va_arg マクロは 
呼び出されるたびに変数 ap を更新しています ( Fig . 2-9 参照)。 

このとき， va_arg マクロに指定する型情報をまちがえないように気をつけてく 
ださい。もし誤った型情報を指定すると，その引数が正しい値として取リ出せな 
いばかりかボインタが狂ってしまい，それ以降の引数がすべて無効になってしま 
うことがあります 8 )。可変長引数の部分は ， C のフ 。ロトタイプチヱックが機 
能しませんから，自分で注意しなければなりません 9 )。 


9) printf 間数などの可変長 
引数の型チェックを行う 
機能が GCC ver .2 に 
追加されましたが，これ 
は GCC が関数の仕様 
を知っているからにすぎ 
ません。 


スタックに格納した型と取り出すときの型は同じでなければならない 


♦ 可変長引数の実際 


最後に，ここまで説明してきた知識をベー 
スに printf 関数に似た簡単なフォーマッ 


卜表示関数を作成してみました (List 2-26 參照)。後は皆さんで考えてみてくだ 


さい0 


List 2-26 •可変長引数の実際例 


1 ： /* 

2 : ** vatest.c : 

3 ： ** 可変長引数を使ったフォーマット表示 

4: */ 

5: # include <stdarg.h> 

6 : # include <stdio.h> 
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7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 
12 

43 

44 

45 


void formatOut (const char *format,...) 

{ 

char ch; 
va_list ap; 

/* ap を初期化*/ 
va_start (ap, format); 

/* format 文字列を調べていく*/ 
while (ch = *format++) { 

/* 7. 以外の文字はそのまま出力する*/ 
if (ch != ”/•，） 

iputc (ch, stdout); 

/* °/〇ならばそれに続く文字によって分類*/ 
else 

switch (*format++) { 
case , s 1 : 

fputs (va_arg (ap, char *) ， stdout); 
break; 
case , c , : 

fputc (va_arg (ap, int), stdout); 
break; 
default : 

fputc (’％’， stdout); 
break; 



/* ap によるアクセスを終わる*/ 
va_end (ap); 

> 

int main (void) 

{ 

formatOut (" # /,s is # /,c\n", "First char", ’F’）； 


このプログラムをコンパイルし実行させると，画面には次のように表示され 
ます。 


A: \> gcc -0 vatest.c 
A: \> vatest.x 
First char is F 
A:\> 
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2.6 


シグナル機構 


❖シグナル機構について 


シグナルとは，ハードウヱアおよびソフトウヱアからランダムに発生する割り 
込みのことです。 c 言語ではこれらのシグナル割り込みを処理するために，シグ 
ナルハンドラを記述することができます。本セクションでは，シグナルの取り扱 
いについて解説します。 


Human 68 k というよりはでは，基 
本的に I CTRL )-1-1 (T| の押下げによって発 
生する SIGINT というシグナルしか扱えません。しかしシグナルの実体は割り込 
みですから，それ以外のシグナルであっても X 68000 および X 68030 の各種割 
り込みを，ライブラリが直接扱えば操作することが可能になります。 

確かに，本来シグナル機構は 0 S がサポートすべき範囲のものなので，それを 
ユーザレベルのが 处理するというのは，あまりよいとはいえないでしょう。 
しかしでは「やれることはやってみる」というスタンスから，従来はあま 
り重視されなかったシグナル機能について，できる範囲内でサポートすることに 
しました。 


♦ Human 68 k とシグナル 


シグナルの種類 


まず，実際にどのようなシグナルが発生 
するのかについて確認しておきましょう。 
L / FC が処理するシグナルには ， Table 2-18 のようなものがありますが，これら 
は大別すると，次の3つに分類されます。 


〇発生区分がソフトウヱア例外のもの 

シグナル SIGABRT ， SIGKILL , SIGTERM , SIGSTOP ， SIGUSR 1, SIGUSR 2 は 
ソフトウヱア例外による割り込みです。ソフトウヱア例外というのは L 75 C 
が自分で発生させる trap 14の例外のことで，おもにほかの処理系との互換 
性のために用意されています。 

〇 発生区分が Human 68 k 例外のもの 

シグナル SIGINT は， Human 68 k 例外による割り込みです。 Human 68 k 
例外というのは， Human 68 k がキーボードをチェックして発生させる trap 
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Table 2-18• の シグナルー覧 


シグナル 

発生区分 

内容 

SIGABRT 

ソフトウヱァ例外 

ABORT シグナル 

SIGINT 

Human 68 k 例外 

CTRL+C イ ン タラブト 

SIGILL 

ハードウヱァ例外 

不正な命令を実行した 

SIGFPE 

ハードウエァ例外 

0 による除算 

SIGKILL 

ソフトウヱァ例外 

KILL シグナル 

SIGBUS 

ハードウヱァ例外 

アドレス エラー 

SIGSEGV 

ハードウヱァ例外 

バス エラー 

SIGALRM 

ハードウエァ例外 

リアルタイムクロック割り込み 

SIGTERM 

ソフトウヱァ例外 

終了シグナル 

SIGEMT 

ハードウヱァ例外 

未定義トラップ 

SIGSTOP 

ソフトウヱァ例外 

STOP シグナル 

SIGUSR1 

ソフトウエア例外 

USR 1 シグナル 

SIGUSR2 

ソフトウヱァ例外 

USR 2 シグナル 


13の例外のこと，ソフトウヱア例外の一種になります。 ただし LIBC では， 
trap 13は利用していません。このことについての詳細は後で述べます。 

〇発生区分がハードウェア例外のもの 

シグナル SIGILL ， SIGFPE ， SIGBUS ， SIGSEGV , SIGALRM , SIGEMT はハー 
ドウヱア例外による割り込みです。ただし正確には，ハードウヱア例外を 
Human 68 k が処理した後に発生する，ソフトウヱア例外のことを意味しま 
す 1 )。 SIGFPE と SIGALRM を除くこれらのシグナルは，現在実行中のプロセ 
スが回復不能な状況になったことを通知するためのものです。 


シグナルハンドラの設定 


Table 2-18 で示したシグナルは，それぞ 
れ内容で述べたような状況が発生すると， 
現在実行中のプログラムに割り込みとして通知されます。実行中のプログラムは 
一時中断され，ライブラリによってそれぞれのシグナルに対応したシグナルハン 
ドラが呼び出されます。 

ユーザがシグナルハンドラに何も設定しなくても，ライブラリにはそれぞれの 
シグナルに対応した標準のシグナルハンドラが存在しています。これら標準のシ 
グナルハンドラは ， Table 2-19 のような動作をします。 

特に複雑な処理をしないプログラムならば，標準のシグナルハンドラのまま利 
用しても問題ありません。しかし，ある程度エラー処理をしなければならないプ 
ログラムを作成するならば，ユーザが独自にシグナルハンドラを用意する必要 
があるでしょう。独自のシグナルハンドラを設定するには， signal 関数を用い 
ます。 


シグナルハンドラは， int 型の引数（シ 
グナル番号）を1つだけもつ 2 koid 型の 
関数です。割り込み処理といっても，実際のめんどうな処理はすべてライブラリ 


♦ シグナルハンドラの作り方 


1) ただし， SIGALRM は純粋 
にハードウエア例外です。 


2)UNIX などでは，割り 
込みに関する情報などが 
より詳しく渡されます。 
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Table 2-19 •標準のシグナルハンドラ 


シグナル 

処理 

SIGABRT 

強制終了 

SIGINT 

強制終了 

SIGILL 

強制終了し，メモリイメージをファイルにダンプ 

SIGFPE 

強制終了し，メモリイメージをファイルにダンプ 

SIGKILL 

強制終了 

SIGBUS 

強制終了し，メモリイメージをファイルにダンプ 

SIGSEGV 

強制終了し，メモリイメージをファイルにダンプ 

SIGALRM 

強制終了 

SIGTERM 

強制終了 

SIGEMT 

強制終了し，メモリイメージをファイルにダンプ 

SIGSTOP 

無視 

SIGUSR1 

強制終了 

SIGUSR2 

強制終了 


が行っていますから，シグナルハンドラではいくつかの注意点を守るだけでかま 
いません。 

List 2-27 を見てください。これは SIGSEGV シグナルに対するシグナルハンド 
ラです。バスエラーによって回復不能になり， SIGSEGV シグナルが発生すると， 
メッセージを表示して終了するように作成されています。 


List 2-27• SIGSEGV シグナルハン 


1： /* 

2 : ** sigsegv.c: 

3: ** SIGSEGV が発生すると，メッセージを表示して終了させるための 

4: ** シグナルハンドラ 

5: ♦/ 

6: #mclude <signal.h> 

7: #include <svs/dos.h> 

8 : 

9 : void sigsegv_handler (int sier .number) 

10： { 

11: _dos_print ("バスエラーが発生しました . 終了します。 \r\n") ; 

12: exit ⑴； 

13: > 


シグナルハンドラは普通の関数と同じよ 
うに書くことができると述べましたが， 
それでも本質は割り込み処理なので，いくつかの制限があります。また，行って 
はいけない禁止事項もあります。 

〇 ハードウエア例外によるシグナルは復帰させてはならない 

SIGFPE と SIGALRM を除くハードウヱア例外シグナルは，プログラムが回復 
不能な状況になったことを表すシグナルです。これらのシグナルハンドラで 
は，必ず最後にプログラムを終了させてください （List 2-27 参照)。もし終了 


♦ シグナルハンドラの注意点 
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させなかった場合は，正常に動作しなくなるだけでなぐ Human 68 k のシ 
ステムそのものが回復不能になることがあります。 

〇リエントラントでない関数を使用してはならない 

シグナルハンドラは割り込み処理です。現在実行中の処理が任意の場所で中 
断したままになっています。ですから，これらの中断している処理に副作用 
をおよぼすような処理をしてはいけません。つまり，リエントラント（再入 
可能）な関数しか使用することができません。 

これはハードウヱア例外シグナルに対するシグナルハンドラなど，シグナ 
ルハンドラ内部でプログラムを終了してしまう場合でも同じことです 。 List 
2-27 で- dos _ print 関数という DOS コールを使用していて， printf 関数や 
puts 関数などの stdio ライブラリを用いていないのはこのためです 3 )。 
リエントラントな関数とは副作用のない関数のことで， auto 型変数だけを利 
用し， static 型や extern 型の変数を参照/変更しない関数のことをいいま 
す。また，当然どこかのメモリ領域を参照したり，書き換えるようなことも 
してはいけません。外部の状況に左右されないことが，リエントラントの条 
件だからです 0 たとえば ， List 2-28 にリエントラントな関数とそうでない関 
数の例をあげてみました。 


ラントな関数 


2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 


/* 

** reent.c: 

** リエントラントな関数，そうでない関数とは.. 
*/ 

/* リエントラントな関数*/ 

void Simp 丄 eSamplel ^double a, double b) 

{ 

/* 引数だけで，外部と一切関係をもたない*/ 


return 2 * a 


b ； 


/* リエントラントでない関数*/ 
void SimpleSample2 (int *array) 

{ 

/* 外部のメモリ領域 array を参照している*/ 
return arrav[0] + array[1] + 10; 


POSIX .1 などではリエントラントな関数とそうでない関数を明確に定義して 
いますが， L /5(? では明確にしていません。これからも仕様の変更などが十 
分に予想されるからです。ただし，我々がリエントラントな関数として作成 
した関数には- - const 型という関数属性の修飾子がついていますから，イン 
クルードファイルを見れば，ある程度 4 )リエントラントかどうか，調べるこ 
とができます。実際に使ってみて試すという方法もありますが，副作用がど 
ういう影響をおよぼすかについては，ある意味で確率的な問題ですから，あ 
まりよい方法とはいえないでしょう。 


3) とはいえ，本当のところ， 
DOS コールが リエント 
ラントとは誰も保証して 
いませんから，これも誤 
りです。 


4 )あまり信用はしないでく 
ださい。 
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いささか矛盾しますが，リエントラントでない関数を使うことが，必ずしも 
いけないわけではありません。というのも，発生するであろう副作用と現在 
実行中のブログラムの相関関係を正しく把握し，干渉が起こらないことを確 
認したうえでならば，リエントラントでない関数を利用することも可能だか 
らです。 


中断したプログラムを邪魔してはならない 


こうしたことを考慮すると，理想的なシ 
グナルハンドラとはごくごく単純な形に 
行きつくことがわかります。そして，事実そのような単純なシグナルハンドラこ 
そが，最も推奨されるシグナルハンドラの書き方です （List 2-29 参照)。 


♦ 理想的なシグナルハンドラ 


List 2-29 •理想的なシグナルハンドラの姿 


1 ： /* 

2 : ** sighand . c : 

3: ** 理想的なシグナルハンドラは割り込みフラグを立てるだけで 

4: ** ある。外部変数を変更するため，リエントラントとはいえな 

5: ** いが，割り込みのためだけに利用されるフラグなので，中断 

6: ** されたプログラムとの副作用の相関関係はない 

7: */ 

8 : # include 〈 signal . h > 

9: 

10: sig _ atomic_t interrupt_flag = 0; /* 割り込みフラグ*/ 
11 : 

12 : void sigalarm_handler (int sig _ number ) 

13: { 

14 : interrupt_flag =1; 

15: > 


5) 要するに，フラグ変数の 
値がレジスタに割り当て 
られてしまうと，割り込み 
によって値が変化したこ 
とがわからないからです。 


List 2-29 のプログラムでは sig _ atomic _ t 型の変数が用いられていますが，こ 
の sig _ atomic _ t 型という変数型は，シグナルハンドラで利用される割り込みフ 
ラグのためのデータ型のことです。 ZJfiC ではこのデータ型を volatile int 型 
に定義していますから，もし int 型以外のデータ型をフラグに用いたい場合は， 
必要なデータ型に volatile 型の修飾子をつけてください。 

この处理は，おもにコンパイラの最適化によって誤動作するのを防ぐためのも 
のです。通常，コンパイラは処理がシーケンシャルに連続して行われるものとし 
て最適化 5 )を行います。ですから割り込み処理によって，値が変化する可能性が 
あることを，教えてやらねばなりません。 

割り込みフラグは volatile 型にすること 
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Chapter 3 

Appendix A 


Appendix A として， ZJ 忍 (7 の用語解説とに関するややハイレべ 
ルな情報を掲載します0本章に記載した内容は，特定の Liec バージョン 
に依存することがあり，将来は変更される可能性がありますから注意し 
てください。 
















































































































































































































ライブラリー第 1 部 


A . LLBC の起動オプション 


LIBC を使用して作成したプログラムを起動すると，起動時に指定した引数が 
そのまま引数の配列として main 関数に渡されます。アプリケーションはこの引 
数の配列を調べて，オプションやファイル名などを取り出すわけですが，これと 
同様にへの起動オプションというものが存在します。 

のオプションとは，起動時に L 仿 C が解釈し，ライブラリ自体の動作を 
決定するためのものです。このオプションは LJ 5 C に対するものなので，ライブ 
ラリが引数配列から抜き取って， main 関数には渡されません。そのためこの才 
プションは，アプリケーションのオプションと区別するために（またアプリケー 
ションの自由度を制限しないため）やや冗長な形式となっています。 

現在，は次のライブラリオプション（起動オプション）を解釈します。 

〇 _+_ s : bytes 

め;把 s で指定したバイト数をスタック領域に割り当てます。このオプションを 
指定しない場合，スタック領域は標準で 32 K バイト確保されます。 -+- s : と 
办 to の間は空白を入れず，また办 to はバイト単位で指定してください。 

〇 -+- h : bytes 

紗 to で指定したバイト数をヒープ領域に割り当てます。ヒープ領域は足りな 
くなった時点で自動的に拡張されるので，この値は初期サイズを指定するた 
めのものです。このオプションを指定しない場合，ヒープ領域は標準で 64 K 
バイト確保されます。 -+- h : と知/打の間は空白を入れず，また办如はバイ 
卜単位で指定してください。 

〇 -+-p 

このオプションを指定すると， main 関数を実行する前にアプリケーションを 
スーパーバイザモードに変更します。その結果， I / O コプロセッサを利用し 
た数値演算が高速化されますが，当然，メモリ保護が効かなくなるなどの危 
険が生じます。このオプションを指定しない場合，アプリケーションはユー 
ザモードで動作します。 

〇 _+_f 

LIBC は 「 ZJBC 1 の数学関数の特徴」 （ P .55) で解説したとおり，コプロセッサ 
が利用可能ならば，それらを用いて数値計算を行います。ただし，いろいろ 
な理由からコプロセッサの代わりにソフトウヱアで計算したい場合がありま 
す。そのような場合は，このオプションを指定してプログラムを起動してく 
ださい。 LIBCU ， 数値演算を FLOAT パッケージを使用して行うようになり 
ます。 
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0 -+-g 

C ++ プログラムを開発する場合， 「 libcplus . a 」（ P .32) で解説したとおり， 
“ libcplus . a ” をリンクする必要があります。しかし，もしこのライブラリを 
リンクし忘れたり，意図的にリンクしたくない場合もあるでしょう。そのよ 
うなときは，このオプションを指定することでプログラム中の グローパルコ 
ンス トラク タ/グローバルデス トラクタを強制的に起動することができます。 

たとえば， “compress. X” というある任意のプログラムを例に，ライブラリ 
オプションの使用法を説明します。このプログラムは非常に多くのスタックを 
消費するので，あらかじめ多めにスタック領域を与えてやらねばなりません。 
“compress.x” を， 256 K バイトのスタック領域とともに起動するには次のように 
タイプしてください。画面の表示例中で，262144というのが 256 K バイトをバイ 
卜単位で表現した値です。 


A :\> compress.x bigfile -+- s : 262144 

この例では compress .x に，2つの引数 bigfile と- +-s : 262144が渡されて 
いますが，このうち実際に main 関数に渡されるのは bigfile だけです。また， 
L / 万のライブラリオプションは任意の位置で指定することができます。 

なお，ライブラリオプションの处理を行う関数については Vol . 2 「 Programmer’s 
Reference 」 の- enargv 関数に関する記述を参照してください。 






B 


LZBC の J 


どうしても必要な場合，は次のようなエラーメッセージを表示します。こ 
のエラーメ ッ セージはプログラムの動作状況によらず，つねにコンソールに表示 
されます。 


〇 スタックオーバーフロー 

下図は，スタックオーバーフローが起こったことを知らせるメッセージです。 
ZJBC はこのメッセージを表示した後，プログラムを強制終了させます。 
GCC で -f stack - check オプションを指定してコンパイルすると，スタック 
チェックつきの実行ファイルができあがります。この実行ファイルは関数呼 
び出しのたびに，スタックボインタがスタック領域からはみ出していないか 
どうかをチヱックします。もしスタック領域をはみ出し，慕走する可能性が 
ある場合はこのメッセージが表示されます。 


libc : stack overflow . 


〇 メモリブロック配置 エラー 

下図は，プログラムを実行するだけのメモリが足りない場合に表示される 
メッセージです。はこのメッセージを表示した後，プログラムを強制終 
了させます。 

このメッセージは，プログラムの実行に必要なスタック領域とヒープ領域が 
確保できないことを意味していますが，ヒープ領域の拉張とは関係がありま 
せん。 main 関数の処理が始まる以前に，スタック領域/ヒープ領域の配置を 
決定する段階で発生するエラーです。この段階では，アプリケーションは何 
も実行されていません。 


11 be: setb 丄 ock failed. 











c 


のエラーコード 


ZJBC で提供されている関数の多くは，実行に失敗した場合 エラーを 示す値 
を返すとともに，変数 eixno に エラーの 原因を示す コードを 設定します。変数 
errno およびエラ ーコード はく errno . h > に定義されており，次のような意味が 
あります。 

なお，文末に回とマークされているのは r X 680 x 0 Develop . & libc IIj に 
付属する LWC で新た に使用されるようになったコードです。 


• E 2 BIG 

子プロセスを起動する際に，親プロセスから子プロセス 

• EACCES 

に渡される引数が長すぎる 

指定したパス名にアクセスできない III) 

• EAGAIN 

リソースに一時的にアクセスできない [III 

• EBADF 

使用していないか，ファイルハンドルか，あるいは不正 

• EBUSY 

なファイルハンドルを指定した 

リソースが使用中である1111 

• ECHILD 

子プロセスが存在しない@ 

• EDEADLK 

デッドロックが起きてしまう III) 

• EDEVFS 

デバイスは指定することができない 

• EDOM 

数学関数で，関数の定義域外の引数を指定した 

• EEXIST 

同名のファイルがすでに存在している 

• EFAULT 

不正なアドレスを指定した 

• EFBIG 

ファイルが大きすぎる 

• EINTR 

シグナルの割り込みによって処理が中断された 

• EINVAL 

不正な引数を指定した 

• EI 0 

物理的なデータ入出力中に何らかのエラーが発生した 

• EISDIR 

ディレクトリを指定することはできない 

• EL 00 P 

シンボリックリンクのネストか 1 罙すぎるか，どこかでルー 

プしている 

• EMFILE 

これ以上ファイルをオープンすることはできない 

• EMLINK 

これ以上ファイルをリンクできない III 」 

• ENAMET 00 L 0 NG 

ファイル名が長すぎる 

• ENFILE 

これ以上ファイルをオープンできない（システム全体） 

• EN 0 DEV 

回 

指定したデバイスが見つからない@ 

• EN 0 ENT 

指定したファイル，あるいはディレクトリが見つからない 











• ENOEXEC 

• ENOLCK 

• ENOMEM 

• ENOSPC 

• ENOSYS 

• ENOTBLK 

• ENOTDIR 

• ENOTEMPTY 

• ENOTTY 

• ENXIO 

• EPERM 

• EPIPE 

• ERANGE 

• EROFS 

• ESPIPE 

• ESRCH 

• ETXTBSY 

• EXDEV 

• EWOULDBLOCK 


不正な実行フォーマットである ( n ] 

これ以上ロックできない@ 

メモリが足りなくなった 

ディスクが一杯になったのでこれ以上書き込めない 
この機能は使用できない 

指定したデバイスはブロックデバイスではない 
ディレクトリを指定しなければならない 
ディレクトリが空でないので削除することができない 
キャラクタデバイスを指定しなければならない 
指定したデバイス，アドレスが見つからない@ 
禁止された操作を行おうとした UU 
パイプが壊れている mi 

数学関数の演算結果が，表現できる値の範囲を越えた 
読み込み専用のファイルシステムである 
キャラクタデバイスに対してシークしようとした 
指定したプロセスが見つからない 
実行ファイルが使用中である@ 

ファイルシステムをまたがってファイルを移動しようと 
した 

デッドロックが起きてしまう @ 






D 


U 万 C が見る環境変数 


ZJJ 5 C の提供する関数群のなかには，環境変数を参照して動作を変化させるも 
のがいくつかあります。現在のバージョンの L / J 5 C は，次の環境変数を参照して 


います。 


• path 

spawnlp 関数や execlp 関数など，外部プログラムを 
実行させる関数は環境変数 path を参照し，指定され 
たプログラムを path ディレクトリから検索します。 
詳細は execlp 関数，あるいは spawnlp 関数を参照し 

てください。当然ですが，この環境変数は必ず設定し 

ておく必要があります。 

• temp 

tmpnam 関数など，テンポラリファイルを作成する関数 
は環境変数 temp を参照し，指定されたディレクトリ 
にテンポラリファイルを作成します。詳細は tempnam 

関数を參照してください。この環境変数は必ず設定し 

ておく必要があります。 

• USER 

では getlogin 関数など，ユーザ名/ユーザ 

LOGNAME 

ログイン名を取得する関数を提供していますが， 

Human 68 k にはこのような概念がありません。そこ 

で L / BC はこれらのユーザ名を取得する場合，環境変 

数 USER ， LOGNAME を参照します。値は環境変数 USER 

の設定が優先されますが，もし USER が未定義ならば， 

環境変数 LOGNAME の値を使用します。また ， LOGNAME 

も未定義ならば固定的に “ root ” が使用されます。 

これらの環境変数は自分で直接設定してもよいですが， 

たとえば “bash . X” や ITA ToolBox の “f ish • x ” を 

“ login . x ” とともに利用する場合は，自動的に設定さ 
れます。詳細は getlogin 関数を参照してください。 

この環境変数は，必要がなければ設定する必要はあり 

ません。 
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• UID 
EUID 


• GID 
EGID 


• SYSROOT 


では getuid 関数や geteuid 関数など，ユーザ 
ID / 実効ユーザ ID を取得する閨数を提供しています 
が， Human 68 k にはこのような概念がありません。 
そこで L 7 BC 7 はこれらの値として環境変数 UID/EUID 
を参照します。それぞれ UID がユーザ ID ， EUID が実 
行ユーザ ID を表します。もし環境変数 EUID が未定 
義ならば，実行ユーザ ID はユーザ ID と等しくなり 
ます。また環境変数 UID も未定義ならば，ユーザ ID 
は0 ( root ) となります 0 

これらの環境変数は自分で直接設定することもできま 
すが， “ fish . x ”，“ bash . x ” などのシヱルが自動的に 
設定します。自分で設定する場合には，ユーザ名の設 
定との整合性が損なわれないように注意してくださ 
い。詳細は getuid 関数， geteuid 関数を参照してく 
ださい。この環境変数は，必要がなければ設定する必 
要はありません。 


L / BC * では getgid 関数や getegid 関数など，グルー 
プ ID / 実効グループ ID を取得する関数を提供していま 
すが， Human 68 k にはこのような概念がありません。 
そこで LIBC は これらの値として環境変数 GID / EGID 
を参照します。それぞれ GID がグループ ID , EGID が 
実行グループ ID を表します。もし環境変数 EGID が 
未定義ならば，実行グループ ID はグループ ID と等 
しくなります。また環境変数 GID も未定義ならば，グ 
ループ ID は0 ( root ) となります 0 
これらの環境変数は自分で直接設定することもできま 
すが， “ fish . x ”，“ bash . x ” などのシヱルが自動的に 
設定します。自分で設定する場合には，ユーザ名の設 
定との整合性が損なわれないように注意してくださ 
い。詳細は getgid 関数， getegid 関数を参照してく 
ださい。この環境変数は，必要がなければ設定する必 
要はありません。 

パスワードファイル （“/ etc / passwd ”） とグルーブファ 
イル （“/ etc / group ”） は名前が固定のファイルです。通 
常，これらのファイルは “ A :/” から読み込まれますが, 
環境変数 SYSROOT を設定することで読み込む位置を 
変更することができます。たとえば環境変数 SYSROOT 
に“ B :/ user ” を設定すると，パスワードファイルは 
“ B : / user / etc / passwd ” が読み込まれます。詳細は， 
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• SHELL 
SYSTEM_SHELL 


• SHELL.OPT 
SYSTEM _ SHELL_OPT 


• SHELL.TYPE 
SYSTEM _ SHELL_TYPE 


•limit.core 


getpwnam 関数あるいは getgrnam 関数などを参照し 
てください。この環境変数は，必要がなければ設定す 
る必要はありません。 

system 関数で，外部プログラムを起動する場合に 
使用する シヱル（コマンド インタプリタ，たとえば 
“ COMMAND . X ” など）を指定します。もしこれが設定さ 
れていない場合， LIBCit “ COMMAND . X ” をシェルとし 
て使用します。 

環境変数 SHELL は自分で直接設定することもできま 
すが， “fish.x” ， “bash.x” などのシヱ ルが自動的に 
設定します。 system 関数が使用するシェルだけを変 
更したければ，環境変数 SYSTEM_SHELL のほうだけを 
変更してください 0 詳細は system 関数を参照してく 
ださい。この環境変数は，必要がなければ設定する必 
要はありません。 

system 関数で外咅 P プログラムを起動する場合に，シェ 
ルに対して引数を渡すために用いられるオプションを 
指定します。もしこれが設定されていない場合 ， LIBC 
は使用するシヱルの形式によって自動的にオプション 
を選択します。この環境変数は，必要がなければ設定 
する必要はありません。 

system 関数で外部 プロ グラ ムを 起動する場合に，使 
用する シヱル（コマンドインタプリタ） のタイフ。を指' 
定します。タイプには， Human 68 k の“ COMMAND . X ” 
形式のものと UNIX ライクな，いわゆる 「シヱル」 
形式のものと2種類あります 0 詳細は system 関数を 
参照してください。この環境変数は，必要がなければ 
設定する必要はありません。 

でシグナルライブラリを用いる場合，バスエ 
ラーや了 ドレスエラーでコアダンプ状態になることが 
あります 1 )。このとき，環境変数 limit_ COre が設定 
されて いない か，その値が0ならば，コアファイルは 
作成されません。また任意の値を指定することで，コ 
アファイルのサイズを制限することができます。なお 
無制限にしたい場合は，一1を設定してください。 


Chapter 3—Appendix A 


1) 詳細については Vol .2 
signal 間数 ( P .289) 
を#照してください。 
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E 


LIBCt フリーウェア 


L /6 C は公開されているさまざまなフリーウェアを積極的に利用し，より豊富 
な機能を提供しています。現在のバージョンの L 7 SC では次のようなフリーウエ 
アに対応しており，プログラム中からその機能を利用することができます。 

• TwentyOne TwentyOne は Human 68 k にパッチを当て，ファイル名を 

21文字認識させたり，複数のピリオドを利用できるように 
する常駐ソフトウェアです。 ZJ 5 C はもちろんファイル名は 
すべて認識しますし，複数ピリオドについても正しく扱え 
るようになっています。ただし， TwentyOne の「大文字小 
文字を区別する」機能は用いないでください。 LIBC はファ 
イル名の比較が必要な場合，大文字と小文字を同じものと 
して認識していますから，この機能を利用すると動作がお 
かしくなります。また TwentyOne が常駐しているかどうか 
は， L / BC の動作と関係ありません。 

•lndrv lndrv は， Human 68 k に UNIX と同じシンポリックリ 

ンクの機能を付加する常駐ソフトウヱアです。 L / BC はこの 
機能を利用することで， lstat 関数などのシンボリックリ 
ンクを正しく操作することができます。現在の バージョン 
の UBC は lndrv の ver .2.12 を基に開発したものですから， 
将来 lndrv が大きく変更された場合，その動作に対する保 
証はありません。なお lndrv が常駐していない場合， lstat 
関数は stat 関数と等しくなり，またシンボリックリンクを 
操作する関数はエラーを返します。 

• execd execd はファイルに「実行属性ビット」を加えることで， 

“• X ”や “. R ” などの拡張子のないファイルもコマンドライ 
ンから実行できるようにする常駐ソフトウヱアです。 LIBC 
はこの実行属性ビットを正しく認識しますので，たとえば 
st at 関数などで実行可能ファイルかどうかを識別すること 
ができます。 execd が常駐しているかどうかは， LffiC の動 
作に関係ありません。はファイルにつけられたビット 
情報のみを参照しています。 
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• HUPAIR 規格 


HUPAIR 規格とは，実行させようとするプログラムに対し 
て，長い引数列を渡すことができるようにと考えられた引 
数の引き渡し手順の規格です。従来のインタフェイスでは, 
実行するプログラムに対して，255バイトまでしか引数を 
渡すことができませんでした。 1/5(7 は，渡された引数を受 
け取る部分，また子プロセスとして外部プログラムを実行 
する際にそのプログラムに引数を渡す部分，これら両方と 
も HUPAIR 規格に準拠しています。したがって HUPAIR 規格 
に準拠した他のプログラムとの間で，長い引数列をやりと 
りすることができます。しかし HUPAIR 規格に準拠していな 
いプログラムとの間は，従来どおりのインタフヱイスで引 
数を渡します。 







F 


LJ 万 C 用語一覧 


最後に， use で使用している用語について簡単に説明します。これ以外にも 
ハードウエアに関連する専門用語が多数でてきますが，それらについてはここで 
は取り上げません。専門書を参考にしてください。 


• DOS ファイルアトリビュート 

ディスクに記録されているファイルの属性ビッ 
卜 （8 ビット） 

• G フォーマット 

printf 関数で用いるフォーマットで， F フォー 

マツトと E フォーマツトの中間の形式 

• HUPAIR エンコード 

HUPAIR 規格に準拠した引数列のまとめ方の 

手順 

• HUPAIR 識別子 

HUPAIR 規格に準拠しているかどうかを表す 

フラグで，プログラムの実行開始位置+4バ 
イトから8バイト “# HUPAIR \0” 

• Julian 日付 

1月1日を0とし，年始めからの通算日で数 

える日付 

• アラインメント 

データの並び方に関する制限。たとえば， 
MC 68000は奇数バイトからのワードデータの 

読み出しはできない 

• アラームシグナル 

指定した時間が経過した時点で発生させるこ 
とができるアラーム予約方式のシグナル 

• エポックタイム 

協定世界時1970年1月1日0時0分0秒 

• エラー 指示子 

stdio ライブラリのフアイルストリームに設 

定され，ストリームがエラー状態であること 

を示す 

•才ープンモード 

ファイルをオープンするときに指定するモー 
ドで，大別すると「読み込みのみ」，「書き込 
みのみ」，「両方」の3種類がある 

• 親プロセス 

子プロセスを実行したブログラム 

• 改行文字 

LF (0 x 0 a ) だが，処理系によっては CR ( OxOd ) 
の場合もある 













• 拡張 UNIX ファイルモード 

Human 68 k の DOS フアイルアトリビュー 

卜と UNIX のファイルモードを両方扱える 

ように拡張した L /6 C 1 独自のファイルモード 

表現 

• 仮想 ユーザ ID 

ューザ ID という概念がない Human 68 k 上 

で仮想的にューザ ID を表現したもの 

• 空文字列 

長さが0の文字列“”のこと 

•カレントシグナルマスク 

現在のシグナルマスクの設定値 

•カレントプロセス 

現在実行中のプログラム 

• キャラクタデバイス 

コンソール “ CON ” ，シリアル ( RS -232 C ) “ AUX ” 

など文字単位の操作しか行えないデバイス 

• クイックソート 

データのソートを行うアルゴリズムの一種 

• グループ ID 

UNIX 用語で，ューザの所属するグループ 

につけられた ID 番号 

• グループファイル 

UNIX 用語で，グループの一覧を納めたファ 

イル 

• コアダンプ 

UNIX 用語で，実行中のプログラムのある 

一瞬のメモリ状態をファイルに保存すること 

• コアファイル 

UNIX 用語で，コアダンプによって作成さ 

れるファイル 

• 子プロセス 

現在実行中のプログラムから呼び出される外 

部ブログラム 

• コンソール 

画面 

•シエノレ 

UNIX 用語で，コマンドインタプリタのこと 

•シグナルセット 

シグナルの一覧表のようなもの 

• シグナルの配信 

シグナル割り込みを発生させること 

• シグナルハンドラ 

シグナル割り込みを処理する関数 

• シグナルペンディングセット 

割り込みが発生しても，アプリケーションに 

配信されていないシグナルの一覧表 

• シグナルマスク 

割り込みが発生してもアプリケーションに配 

信されないようにするシグナルの一覧表 

• 指数形式 

“1.57863 e -67” のような正規化された数値 

表現 


• システム エラーコード 


Human68k の DOS コールが返してくるェ 
ラーコード 
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• システム制限値 

メモリの最大容量など，アプリケーションに 

許されるさまざまな最大値 

• 実行属性ビット 

フリーウェアである execd が使用する DOS 

ファイルアトリビュートのなかの1ビット 

• 実時間 

現実世界の時間 

•ジャンプポイント 

setjmp 関数で記憶されたプログラム中の任 

意の位置 

• 終端指示子 

stdio ライブラリのフアイルストリームに設 

定され，ストリームがファイルの終端に達し 

たことを示す 

•終了コード 

プログラムの実行結果として親プロセスに渡 

される整数値 

• 詳細時間 

年月日，時分秒の形式で表現した時間 

• シンポリックリンク 

別のファイルへの道順が書いてあるファイル 

で，このファイルをアクセスすると，その道 

順にそって別のファイルにアクセスされる 

• スタックフレー厶 

関数に渡された引数や，その関数で使用する 

ローカル変数などを記憶しておくスタック領 

域のなかの一領域 

• スタック領域 

関数との間の引数の受け渡しやローカル変数 

のために使用されるメモリ領域 

• 大域ジャンプ 

10 ngjmp 関数と setjmp 関数を用いて行う， 
関数の枠を越えた処理の分岐 

• タイムゾーン 

時間帯 

•タイ厶ゾーン情報 

時間帯の情報で，「時差」，「夏時間の有無」， 

「時間帯の名称 j など 

• 端末デバイス 

キャラクタデノくイス 

• 地域時間 

地域のローカルな時間 

• 地域時間情報 

タイムゾーン情報 

•ディレクトリエントリ 

ファイルのサイズ/変更時間，ディスク内の 

位置などを記しているデータ 

•ディレクトリストリーム 

ディレクトリファイルのなかのディレクトリ 

エントリのデータ列を，ストリームとして表 

現したもの 

• テキストモード 

1行の終わりを示す LF を CR ， LF の2バイト 

として扱うモード 
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•デリミタ 
• トークン 
• バイナリ サーチ 
• バイナリ モー ド 


• パイプ 


• パス区切り記号 

• パスワードファイル 
• ビルトイン関数 


• ファイルアクセスモード 

• ファイルストリーム 

• ファイルハンドル 

• ファイルポインタ 

• 物理ドライブ番号 

• ブレーク値 
• プロセス ID 

• ページ 

• メモリ管理ポインタ 

• メモリブロック 
• ユーザ ID 

• 読み込み禁止ファイル 


区切り記号 

区切り記号で区切られた部分文字列 
データの 検索を行う アルゴリズムの一種 

1行の終わりを示す LF をそのまま1バイトで 
扱うモード 

UNIX 用語で ， FIFO (先入れ先出し）方式で 
データを入出力することができるデバイス 


パス名のなかのディレクトリ区切りを表現す 
る記号で， UNIX では“/”， Human 68 k や 
MS-DOS では“\” 

UNIX 用語で， ユーザ ー覧を納めたファイル 

GCC が出力するコードのなかに直接埋め込 
まれる実体のない関数。インライン関数の 
一種 

ファイルの種類やアクセスの許可/不許可な 
どを表したデータ 

ファイルの中身をデータの連続体（ストリー 
ム）として表現したもの 

低水準ファイル入出力で，特定のファイルを 
表す識別子 

ファイルの先頭から終わりまでで，現在見て 
いる位置 

Human 68 k が起動時に認識したドライブ 
番号 

ヒープ領域の終端の位置 

UNIX 用語で，現在実行中の特定のプロセ 

スを表す識別子 

UNIX 用語で，_を使った仮想記憶で OS 
が一度に扱うメモリ単位 

Human 68 k の管理するメモリブロックの先 
頭に記録されている管理情報 

任意サイズのメモリ領域 

UNIX 用語で，特定のユーザを表す識別子 

存在するが，中身を見ることが禁止されてい 
るファイル 
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• 乱数シード 
• リアルタイムクロック 
• リエントラント 

• ' J ンクカウント 

• 暦時間 

• レジスタ渡し 

•論理ドライブ番号 


乱数を発生させる乱数形列の基礎となるもの 


X 68000 および X 68030 では RTC のこと 

再入可能（実行環境と一切の関わりを持たな 
い関数） 


UNIX 用語で，ハードリンクしたときに何 
か所からリンクされているかを記録するカウ 
ンタ 

エポックタイムからの通算秒数で時間を表現 
する方法 

関数間の引数のやりとりを，スタックではな 
くレジスタを介して行う方法 

物理ドライブを，仮想ドライブなどの機能を 
用いて変更した後のドライブ番号 
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Chapter 4 

Appendix B 


Appendix B として， ZJ 忍 (7 を作成するうえで参照した Human 68 k の 
内部情報を掲載します。ただし，この資料は公式な資料ではありません 
から，記載された情報が正しいとはかぎりません。また， Human 68 k の 
バージョンによっても異なりますので，あくまでも参考程度にとどめて 
おいてください。 
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A . システムのエラーコード 


最初に Human 68 k の DOS コー ルが返す エラーコード の一覧表と SCSI/IOCS 
コールが 返す エラーコー ドの一覧表を掲載します。 

〇 DOS コールの エラー コード 


コード 

解説 

-1 

無効なファンクションコールを実行した 

-2 

指定したファンクション名は見つからない 

-3 

指定したディレクトリが見つからない 

-4 

これ以上ファイルをオープンできない 

-5 

ディレクトリやボリュームラべルは指定できない 

-6 

不正なファイルハンドルを指定した 

-7 

メモリ管理領域が破壊された 

-8 

メモリが足りなくなった 

-9 

無効なメモリ管理ポインタを指定した 

-10 

不正な環境を指定した 

-11 

実行ファイルのフォーマットがおかしい 

-12 

不正なファイルアクセスモードを指定した 

-13 

不正なファイル名を指定した 

-14 

不正な引数を指定した 

-15 

不正なドライブ番号を指定した 

-16 

カレントディレクトリは削除できない 

-17 

IOCTRL できないデバイスを指定した 

-18 

これ以上ファイルが見つからない 

-19 

このファイルには書き込みできない 

-20 

すでに存在するディレクトリをす旨定した 

-21 

ディレクトリが空でないので削除できない 

-22 

ディレクトリが空でないのでリネームできない 

-23 

ディスクが一杯になった 

-24 

これ以上ファイルを作成できない 

-25 

指定された位置にはシークできない 

-26 

多重にスーパーバイザモードに入ろうとした 
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Chapter 4 — Appendix B 


コード 

解説 

-27 

未使用 

-28 

同名のスレッドがすでに存在する 

-29 

メッセージが受け取られなかった 

-30 

不正なスレッド番号を指定した 

-31 

未使用 

-32 

シエアリング可能なファイル数を越えた 

-33 

ロック違反 


o SCSI のエラーコード 
• 上位 INTS ( SPC の割り込み原因） 


ビット 

意味 

16 

RESET コンデイション割り込み 

17 

SPC ハードウエア割り込み 

18 

セレクションタイムアウト割り込み 

19 

実行しようとする転送フヱーズと SCSI 上での要求されている転送フエー 
ズとが一致しなかったか，あるいは転送実行中に他の転送フヱーズが 

要求されてきたときの割り込み 

20 

SPC に対するコマンド終了割り込み 

21 

DISCONNECTED 割り込み 

22 

RESELECTED 割り込み 

23 

SELECTED 割り込み 


各ビットは，0で割り込みなし，1で割り込みありを表す。 

• 下位 PSNSf SCSI バス上の制御信号の状態） 


ビット 

意味 

0 

I/O (データの方向を示す信号） 

1 

C/D (コマンドかデータフェーズかを示す信号） 

2 

MSG (メッセージフェーズを示す信号） 

3 

BSY ( SCSI バスの使用中を示す信号） 

4 

SEL (選択信号） 

5 

ATN (アテンシヨン条件を示す信号） 

6 

ACK (データ転送許可信号） 

7 

REQ (データ転送要求信号） 

8 

0 

9 

0 


各ビットは，信号が0でノンアクティブ，1でアクティブであることを表す。 
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Human68k の内部情報 


ZJJ ? (:を作成するにあたって，我々が収集した Human 68 k の内部情報をわ 
かっているかぎり掲載します。ただし，この情報はいろいろな人が解析した結果 
をまとめたものであり，公式な資料として公開されているものではありません。 
したがって，ここに記載されていることはあくまでも参考程度に考えてくださ 
い。また，この情報はほとんど Human 68 k ver .2 を基に作成されたものなので， 
Human 68 k ver .3 では異なることもあります。 

また， Human 68 k ver .2.03(92 年版）とは，起動メッセージの “ Copyright ” 
部分に “92” と表示されるバージョンのことを言います。 

〇 Human 68 k のワークエリアの内部情報 


アドレス 

解説 

$1800 -$lbff 

DOS コールべクタテーブル（各 4 バイト） 

$ lbcO ( L ) DOS コール $fffO retshell 

$ lbc 4( L ) DOS コール $fffl ctlabort 

$ lbc 8( L ) DOS コール $ fff 2 errabort 
$ lbeO ( L ) DOS コール $ fff 8 open_pr 
$ lbe 4( L ) DOS コール $ fff 9 kill.pr 
$ lbfc ( L ) DOS コール $ffff change.pr 

上記べクタに関しては処理をのっとるのではなく，ユー 
ザ処理ルーチンが本来の処理に加えてコールされるだけ 

である 

$ lcOO ( L ) 

現在のプロセスにおけるメモリ最終アドレス+1 

$ lc 04( L ) 

現在のプロセスにおけるメモリ先頭アドレス 

$ lc 08( W ) 

inDOS フラグ 

$ lcOa ( B ) 

実行中の DOS コールフアンクシヨンナンバー（非マル 

チタスク環境下では， inDOS フラグが0から1に変わる 
タイミングでしかセツトされない） 

$ lcOb ( B ) 

NEWFAT = で指定した値（初期値：$6815の内容） 

$ lcOc ( W ) 

IOCTRL ( U ) 第1パラメータ（初期値： 3) 

$ lcOe ( W ) 

IOCTRL ( ll ) 第2パラメータ（初期値：100) 

$ lclO ( W ) 

VERIFY フラグ 




















アドレス 

解説 

$ lcl 2( B ) 

BREAK フラグ 

$ lcl 3( B ) 

CTRL + P フラグ 

$ lcl 4( B ) 

プロセス切り替えのタイミングであることを示すフラグ 

$ lcl 5( B ) 

カレントドライブ番号 

$ lcl 6( B ) 

trap #11 STOP キー 

bit 7 と bitO が変化するが，詳細は不明 

$ lcl 7( B ) 

trap #10リセット/パワーオフの hook に入ったときに 

1になるフラグ。これが1だと終了処理後リセット？ 

$ lcl 8( L ) 

trap #10リセット/パワーオフの hook に入ったとき 
の d 0 退避領域（リセット/パワー OFF 判定フラダ？） 

$ lclc ( L ) 

デハ*イスチエインの最後のデバイスへッダへのポインタ 

$ lc 20( L ) 

HUMAN . SYS の MCB アドレス（メモリチエインの先頭） 

$ lc 24( L ) 

HUMAN . SYS のメモリブロックがどこまで使われている 
かを示す。スーパーバイザ領域はこの値を基に 8 K バイ 

トバンダリで設定される 

$ lc 28( L ) 

現在のプロセスの PSP アドレスを格納してあるワーク 
を指すボインタ (Human68k ver .2.03-92 年版だと 
$12 b 54 で， $12 b 54 には現在のプロセスの PSP アドレス 
が格納されている） 

$ lc 2 c ( L ) 

標準 FCB 以外（ファイルハンドルが5以上）の FCB イン 
デックステーブルへのポインタ（バッファの終端 +1) 

$ lc 30( L ) 

FCB テーブルへのポインタ（予備 FCB インデックステー 
ブルの終端 +1) 

$ lc 34( L ) 


$ lc 38( L ) 

カレントディレクトリテーブルへのポインタ 

$ lc 3 c ( L ) 

物理デバイス情報テーブルへのポインタ 

$ lc 40( L ) 

SHARE = 管理構造体の先頭アドレス 

$ lc 44( L ) 

C 0 MM 0 N = ポインタ 

$ lc 48( L ) 

C 0 MM 0 N = ポインタ 

$ lc 4 c ( L ) 

C 0 MM 0 N = ポインタ（バッファの終端？） 

$ lc 50( L ) 

プロセス構造体テーブルトップへのポインタ 

$ lc 54( L ) 

現在のプロセスのプロセス構造体へのポインタ 

$ lc 58( W ) 

最大プロセス数 （ PR 0 CESS = の第1引数で指定した値 一 1 ) 

$ lc 5 a ( W ) 

現在生成されているプロセスの数 

$ lc 5 c ( L ) 

DOS コール時のベクタブランチ直前の a 7 の値 （inDOS 
フラグが0から1に変わるタイミングでしかセットされ 
ない） 

$ lc 60( W ) 

アボート時の SR 

$ lc 62( L ) 

アボート時の SSP 

$ lc 66( L ) 

デフォルトの trap #11処理ルーチンへのポインタ 

$ lc 6 a ( L ) 

デフォルトの trap #10处理ルーチンへのポインタ （ROM 
をす旨しており，： jmp させると IPL する） 

$ lc 6 e ( W ) 

最大ハンドル番号 （ FILES = 設定値 +2) 












































アドレス 

解説 

$ lc 70( W ) 

BUFFERS ^ 第 2 パラメータ（初期値：$6804の内容） 

$ lc 72( B ) 

BUFFERS : 第1パラメータ 

$ lc 73( B ) 

最終ドライブのドライブ番号 （ LASTDRIVE = の内容） 

$ lc 74( B ) 

ドライブ数関連（初期値：$6807の内容） 

$ lc 75( B ) 

接続されているドライブ数？ 

$ lc 76( W ) 

SHARE = ファイル数（初期値： $680 a の内容で93まで） 

$ lc 78( W ) 

SHARE = 領域数（初期値： $680 c の内容で266まで） 

$ lc 7 a ( L ) 

SHARE = 管理バッファのサイズ 

$ lc 7 e (26 B ) 

ドライブ配置テーブル（ドライブ番号変換用） 

$ lc 98( L ) 

OPEN した FCB のバッファフラッシュ関係のポインタ？ 

$ lc 9 c ( L ) 

OPEN したファイルハンドルのバッファフラッシュ関係？ 

$ lcaO ( B ) 

EXEC 関連フラグ 

$ lcal ( B ) 

EXEC のモード 

$ lca 2( B ) 

INS キーの ON / OFF フラグ 

$ lca 3( B ) 

trap #1 4 する前に0,後に 一 1? 

$ lca 4( L ) 

GETC バッファ読み込みポインタ？ 

$ lca 8( W ) 

GETC バッファ残りカウンタ？ 

$ lcaa ( L ) 

EXEC 関連ボインタ （ MCB +$100) 

$ lcae ( L ) 

プロセスの終了コード 

$ lcb 2( L ) 

最後に実行したコマンドライン文字列へのポインタ 

$ lcb 6( L ) 

CLOCK デバイスのデハ•イスへッダへのポインタ 

$ lcba -$67 ff 

Human68k ver .2.03 までは未使用領域のはず 

$6800 

HUMAN . SYS 開始アドレス ( OS スタック下限？） 


o Human 68 k の内部デフオルト値 


アドレス 

解説 

$6802 ( B ) 

FILES (15) 

$6803 ( B ) 

BUFFERS バッファ数 (20) (2 〜 249) 

$6804 ( W ) 

BUFFERS バッファサイズ (1024) (1024 〜 32768) 

$6806 ( B ) 

LASTDRIVE 番号 (25) 

$6807 ( B ) 

DRIVES 関連 (25) 

$6808 ( B ) 

BREAK フラグ （0) 

$6809 ( B ) 

VERIFY フラグ （0) 

$680 a ( W ) 

SHARE ファイル数 （0) 

$680 c ( W ) 

SHARE 領域数 （0) 

$680 e ( L ) 

COMMON 領域サイズ （0)-1024 (1024 K バイト） 

$6812( B ) 

PROCESS 第1引数 （0) 

$6813( B ) 

PROCESS 第2引数 （0) 




















































アドレス 

解説 

$6814( B ) 

PROCESS 第3引数 （0) 

$6815( B ) 

NEWFAT (0) 


以降，表中で “$ A :$ B ” と表記しているのは， “$ A ” が Human 68 k ver .2.02 で 
のアドレス，が Human 68 k ver .2.03(92 年版）でのアドレスを意味してい 
る。ただし Human 68 k ver . 2.03 (91 年版）の場合は，92年版から一2したアドレ 
スになる。 


アドレス 

解説 

$????? :$07 d 50 

HUMAN.SYS の MCB 

$????? :$07 d 58 

HUMAN . SYS のメモリブロックの終端アドレス（スーハ。一 
バイザ領域のリミットアドレス） 

$????? :$07 d 60 

HUMAN.SYS の PDB 


〇マルチタスク関連の内部情報 


アドレス 

解説 

$????? :$0 e 914( W ) 

プロセス切り替えが， DOS コールによるものであるの 
か，割り込みによるものかのフラグ （0 で DOS コール） 

$????? 

$0 e 916( L ) 

NMI ベクタ保存ヮーク 


$0 e 91 a ( L ) 

タイムカウンタ （10 ms ごとに +1) 

$????*? 

$0 e 91 e ( L ) 


$????? 

$0 e 922( B ) 

レベルカウンタ 

$????*? 

$0 e 923( B ) 

レベルカウンタのインターパル値 

$????? 

$0 e 924( L ) 

プロセス間通信八ッファへのポインタ 

$????? 

$0 e 938(16 B ) 

プロセス名 

$????? 

$0 df 4 c 

Timer - D 割り込みハンドラのエントリアドレス 

$*????? 

$0 df 88 

DOS コール終了のタイミングでの change pr 


$0 el 22 

NMI 割り込みハンドラのエントリアドレス （ kill_pr 
と change pr の実行中） 

$????? 

$0 el 2 a 

NMI 割り込みハンドラのエントリアドレス 

ft ；????? 

$0 e 680 

IOCS TIMERDST hook のエントリアドレス 

$????? 

$0 e 766 

trap #14エラー表示ハンドラのエントリアドレス 

$????? 

$0 e 6 a 0( B ) 

inNMI フラグ 

$????? 

$0 e 6 al 

.even 

$?*???? 

$0 e 6 a 2( L ) 

NMI ベクタの保存ヮーク 

$????? 

$0 e 6 a 6( L ) 

time . pr の戻り値 

$??*??? 

$0 e 6 aa ( L ) 

元の時間 




























































ライブラリー第 1 部 


アドレス 

解説 

$????? :$0 e 6 ae ( B ) 

タイムスライスレベル（現在値） 

$????? :$0 e 6 af ( B ) 

タイムスライスレベル（初期値） 

$????? :$0 e 6 b 0 

HUMAN.SYS のプロセス間通信バッファ構造体 

$????? :$0 e 6 c 4 

HUMAN.SYS のプロセス名 


〇内蔵デバイスドライバの情報 


アドレス 

解説 

$????? :$0 eac 2 

NUL デバイスエントリ 

$????? :$0 eb 5 a 

CON デバイスエントリ 

$????? :$0 f 6 e 6 

AUX デバイスエントリ 

$????? :$0 f 7 c 0 

PRN デバイ スエントリ 

$?????:$0 f 82 a 

LPT デバイスエントリ 

$?????:$0 f 8 e 0 

CLOCK デパイスエントリ 

$?????:$0 f 9 d 0 

DISK 2 HD デバイスエントリ 


〇データ領域の内部情報 


アドレス 

解説 

$????? :$0 fedc ( L ) 

malloc ポインタ 

$????? :$0 fee 0( B ) 


$????? :$0 feel ( B ) 


$?????:$0 feee (256 B ) 

デフォルトのシェル “COMMAND / P ” 

$?????:$0 ffdf ( S ) 


$?????:$0 fffa ( S ) 


$?????:$ 10009 ( S ) 


$?????:$10027( S ) 


$?????:$ 10029 ( S ) 


$?????:$10038( S ) 

c ぃ C ，， 

$?????:$ 1003 a ( S ) 

‘‘\ r \ n \0’， 

$?????:$ 1003 e (4 B ) 


$?????:$ 10042 ( S ) 

“ path :” 

$?????:$10048( B ) 


$?????:$ 10049 ( S ) 

EXEC で検索する拡張子テーブル 

$?????:$ 10050 ( S ) 

EXEC で検索する際に補完する“•*，’ 

$?????:$ 10054 ( B ) 


$?????:$10055(9 B ) 



120 





































































Chapter 4 — Appendix B 


0 エラー表示ハンドラで使用される領域 


アドレス 

解説 

$????? :$1005 e (2 W ) 

エラーメ ッ セージ 座標 （ X ， Y) 

$?????:$10062 (2 W ) 

エラーメ ッ セージ 座標 （ X ， Y) 

$?????:$10066 (2 W ) 

エラーメ ッ セージ 座標 （ X ， Y) 

$?????:$1006 a (2 W ) 

エラーウインドウ座標 （ X ， Y ) 

$????? :$1006 e ( S ) 

エラーメッセージ 

$?????:$10078 ( S ) 


$?????:$ 10087 ( S ) 


$?????:$ 1008 d ( S ) 


$?????:$10093( S ) 


$?????:$ 10096 ( S ) 


$?????:$100 cb ( S ) 

Bus error 

$?????:$100 e 8( S ) 

Address error 

$?????:$ 10105 ( S ) 

Undefined instruction 

$?????:$ 10122 ( S ) 

Devision by zero 

$?????:$ 1013 f ( S ) 

CHK execution 

$?????:$ 1015 c ( S ) 

TRAPV execution 

$?????:$10179( S ) 

Supervisor command 

$?????:$ 10196 ( S ) 

Interrupt 

$?????:$101 b 3( S ) 

Float package not installed 

$?????:$101 d 0( S ) 

Illeagl unit number 

$?????:$ 10205 ( S ) 

Disk not ready 

$?????:$ 1023 a ( S ) 

Illegal device command 

$?????:$ 1026 f ( S ) 

CRC error 

$?????:$102 a 4( S ) 

Broken FAT 

$?????:$102 d 9( S ) 

Seek error 

$?????:$1030 e ( S ) 

Invalid media 

$?????:$ 10343 ( S ) 

Sector not found 

$?????:$ 10378 ( S ) 

Printer not ready 

$?????:$103 ad ( S ) 

Write error 

$?????:$103 e 2( S ) 

Read error 

$?????:$10417( S ) 

Error occured 

$?????:$ 1044 c ( S ) 

Disk protected 

$?????:$10481( S ) 

Not writetable 

$?????:$104 b 6( S ) 

Sharing error 

$?????:$104 ec ( W ) 

保存/復元されるコントラスト値のワーク 

$?????:$104 ee (16 W ) 

保存/復元されるテキストパレ ッ ト値のワーク 

$?????:$ 105 0 e ( W ) 

アボートを選択すると1になる。パレ ッ トの復元をする 

かどうかのフラグとして利用 
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アドレス 

解説 

$?????:$10510 (4 W + L ) 

keep ( x , y ), set ( x , y ), size 

$????? :$1051 c (1664 B ) 

テキストパレット 0 入出カバッファ 

$????? :$10 b 9 c (1664 B ) 

テキストパレット1入出カバッファ 

$?????:$1121 c (10 B ) 

10進/16進変換用ワーク 


o CON デバイスで使用される領域の情報 


アドレス 

解説 

$????? 

$11226( Bxl 5) 

チヱックテーブル （ knjctrl ) 

$????? 

$11235(5 B ) 

チヱックテーブル （ knjctrl ) 

$????? 

$1123 a (5 B ) 

チェックテーブル （ knjctrl ) 

$????? 

$11250( L ) 


$??*?*?? 

$11254(32 B ) 


$????? 

$11274( W ) 



$11276( W ) 

sftsns のステータス 

$????? 

$11278(8 B ) 

rmacnv の al 

¢777?? 

$11280(8 B ) 

rmacnv の a 2 

$????? 

$11288( B ) 


ffi ????? 

$11289( B ) 


{ ft ????? 

$1128 a (1536 B ) 

テキストパレット〇の入出カバッファ ( hendsp ) 

$????? 

$1188 a (1536 B ) 

テキストパレット1の入出カバッファ ( hendsp ) 


$ lle 8 a (1280 B ) 

テキストパレット0の入出カバッファ ( hendsp ) 

朱？？？？？ 

$1238 a (1280 B ) 

テキストパレット1の入出カバッファ ( hendsp ) 


$1288 a ( B ) 

conctrl 

$????? 

$1288 b ( B ) 

conctrl 

$????? 

$1288 c (712 B ) 

function key define data 

$12 dc 8 

$12 b 54( L ) 

カレント PSP ポインタ 

$12 dcc 

$12 b 58(12 B ) 

ファイルハンドルの使用/未使用のビットマップ 

$12 dd 8 

$12 b 64(5 W ) 

FCB 関連 

$12 de 2 

$12 b 6 e (5 W ) 

標準ファイルハンドル（〇〜 4 )の FCB インデックステー 

ブル 

$12 dec :$12 b 78( W ) 

ファイルハンドル5の FCB インデックス 

$12 dee :$12 b 7 a (480 B ) 

標準ファイルハンドル （0 〜 4) の FCB 

$12 b 7 a … stdin 

$12 bda … stdout 

$12 c 3 a … stderr 

$12 c 9 a … stdanx 

$12 cfa … stdprn 

$12 fce :$12 d 5 a (96 B ) 

ファイルハンドル 5 の FCB 































































Chapter 4 — Appendix B 


アドレス 

解説 

$1302 e :$12 dba (260 B ) 


$13132 :$12 ebe ( B ) 

ブレークフラグ ( ON / OFF / KILL ) (ブート時の一時 
ヮーク） 

$?????:$12 ecO ( L ) 

bind ファイルオープンフラグ （クローズ されると 一 1) 

$?????:$12 ec 4( L ) 

DOS コール初期エントリテーブル 


〇 FCB の内部情報 


オフセット 

サイズ 

内容 

$00 

B 

リンクカウンタ （ DUP されると1加算される） 

+$01 

B 

装置情報 

キャラクタデバイスの場合 
bit 0 ... 1:標準入カデバイス 

bit 1 ... 1:標準出カデバイス 

bit 2 ... 1: NUL デバイス 

bit 3 ... 1 : CLOCK デパイス 

bit 4 

bit 5 .. • 0 : COOKED 1 : RAW 

bit 6 

bit 7…1 

ブロックデバイスの場合 

bit 0-4 • •. :物理ドライブ番号 

+$02 

L 

デバイスドライバへのボインタ （ CHAR ) 

内部 DPB へのポインタ （ BLOCK ) 

+$06 

L 

ファイルボインタの値 

+ $0 a 

L 

排他制御情報へのポインタ 

+ $0 e 

B 

アクセスモード 

+ $0 f 

B 

ブロックデバイスの場合 

ディレクトリエントリのセクタ内位置 （0 〜 31) 

キャラクタデバイスの場合 
未使用 ($00) 

+$10 

B 

アクセス中のクラスタ中のセクタ 

+$11 

B 


+$12 

W 

アクセス中のクラスタ番号 

+$14 

L 

アクセス中のセクタ番号 

+$18 

L 

1/0バッファ先頭 

+ $lc 

L 

ブロックデバイスの場合 

ディレクトリエントリのセクタ番号 

キャラクタデバイスの場合 
未使用($00000000) 

+$20 

L 

ファイルポインタ移動の上限 


123 





































ライブラリー第 1 部 


オフセツ 


+$20 


+$24 


+ $2 c 


+ $2 f 


+$30 


+ $3 a 


+ $3 c 


+ $3 e 


+$40 


+$44 


サイズ 


8 B 


3 B 


10 B 


7 L 


内容 


ファイルボインタ移動の上限 


ファイル名1 ( あまった部分は$ 2 〇) 


ファイル拡張子（あまった部分は$ 2 〇) 


フアイル属性 


bit 

0 • 

• 読み込み専用 

bit 

1• 

• 不可視 

bit 

2 . 

. システム 

bit 

3 • 

• ボリューム 

bit 

4 • 

•ディレクトリ 

bit 

5 • 

. 通常のファイル 

bit 

6 


bit 

7 



ファイル名2 (あまつた部分は $00) 


時刻 

bit 15〜11•.•時 
bit 10〜05 •.•分 
bit 04〜00 ... 秒 x 2 


日付 

bit 15〜09 ••.年 
bit 08〜05 •••月 
bit 04〜〇〇 •.•日 


先頭 FAT 番号 


フアイルサイズ 


未使用 ( Sffffffff ) 
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o DOS コール時のベクタブランチ直前の a 7 の値 


アドレス 

解説 

$ lc 5 c ( L ) 

DOS コール時のべクタブランチ直前の a 7 の値 


実際のスタックフレーム 


dl 

d 2 

d 3 

d 4 

d 5 

d 6 

d 7 

aO 

al 

a 2 

a 3 

a 4 

a 5 

a 6 

a 7 


DOS コールの INTVCS などでべクト 
ルをうばった処理ルーチンから，直 
接レジスタに値を返したい場合は， 
$ lc 5 c からポインタを取リ出し，該 
当する位置に値をセットしてリター 
ンするだけでよい。あとは DOS が 
自動的に処理する。 
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〇カレントディレクトリテーブルの情報 


アドレス 

解説 

$ lc 38( L ) 

カレントディレクトリ テーブルへの ポインタ 



64 

68 

69 

70 

74 

76 

78 — 




オフセット 

内容 

+0 

現在のカレントパスをフルパスで示す（仮想ドライブの場合はマウン 
卜されているドライブのディレクトリ名）。区切記号は$09が“\”の 

代わりに使われている。ターミネータは NULL 

+64 

つねに NULL 

+68 

つねに0 

+69 

仮想ドライブ情報 

$40 ... リニアドライブ 

$50 .•.仮想ドライブ 

$60 ... 仮想ディレクトリ 

+70 

物理デバイス情報へのポインタ 

+74 

つねに $ffff ( ドライブ Z : は$0000になっている） 

+76 

つねに$0002 
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〇物理デバイス情報 テーブルの 情報 


アドレス 

解説 

$lc3c(L) 

物理デバイス情報テーブルへのボインタ 



〇—— 
2 

6 

10 

12 

14 

17 

18 
20 
22 
24 
26 
28 

30—— 




オフセット 

内容 

+0.B 

装置番号 

+1.B 

ユニット番号 

+2.L 

デバイスへツダへのボインタ 

+6.L 

次のテーブルへのポインタ 

+10.W 

1 セクタ当たりのバイト数 

+12.W 

1 クラスタ当たりのセクタ数一 1 

+ 14.W 

FAT の先頭セクタ番号 

+ 16.B 

FAT 領域の数 

+17.B 

1個の FAT 領域に使用するセクタ数 

+18.W 

ルートディレクトリのエントリ数 

+20. W 

データ部先頭セクタ番号 

+22. W 

総クラスタ数 +1 

+24. W 

ルートディレクトリ先頭セクタ番号 

+26. B 

メディアバイト 

+28. B 


+30. W 

つねに$0002 
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〇ドライブ配置テーブル（ドライブ番号変換用） 


アドレス 

解説 

$ lc 7 e (26 B ) 

ドライブ配置テーブル （ ドライブ番号変換用） 



ドライブ名に対して，現在実際に割り当てられているドライブ番号がそれぞれ 
格納されている（ドライブ A :=$00， B :=$02 … Z :=$19)。“ drive . x ” で入れ替 
えると， このテーブルは 変更される。故意に同じ番号をセットするとおもしろい 
動作をする。 


〇 _ dos_s .process 関数により確保されるプロセスメモリ空間の構造 

大もとのメモリブロックの属性が $ fd になっていて，そのブロックを細切れに 
分けている。ヘッダや構造に関しては通常のメモリブロックと同様で，単にチェ 
インがサブメモリで完結しているだけである。 


〇 メモリブロック属性 


コード 

意味 

$ff 

常駐メモリブロック （ KEEP ) 

$f e 

MEMDRV ? 

$fd 

サブメモリブロック？ 
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〇 X 形式実行ファイルの情報 


オフセット 

解説 

+$00 ( W ) 

XMAGIC 

+$02 ( W ) 

メモリ割り当てモード 


# /.〇〇 

•••通常 


7.10 

••.上位メモリ ( malloc 2(2)) 


7.01 

•••最小メモリ （ malloc 2( l )) 

+ $3 c ( L ) 

バイン 

ド情報までのオフセット 


ただし Human 68 k ver . 3.00まではバグがあり，メモリ割り当てモードのビッ 
卜1(上位メモリへの割り付け）しか有効ではない。また，ビット0のビット位置 
に関しては推測でしかない。 


〇 Z 形式実行ファイルの情報 


オフ セツ ト 

解説 

+ $00( W ) 

ZMAGIC ($601 a ) 

+$02 ( L ) 

テキストサイズ 

+$06 ( L ) 

データ サイズ 

+ $0 a ( L ) 

BSS サイズ 

+ $16( L ) 

ロー ドアドレス 

+ $ la ( W ) 

d 5 


合計 $2 c バイトである。 


〇 Human 68 k の common 領域 


common 領域の最大サイズは1024 K バイトである。 
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あとがき 


B ともあろうか執筆期間中にバイクに乗っていたら，11トントラックに 
“スコーン”とぶつけられ（私は被害者なのねん)，さらに対向車線の乗 
用車とも大当たりして（宝クジでも買っときゃよかった...)，右手の指2本と右足 
を骨折して入院していたのは，なにを隠そうこの私です（環状7号線をご通行中 
だった皆様，大変ご迷惑おかけしました)。 

そのため，入院，リハビリと，かなりの期間を費やしてしまい，当初の予定よ 
り，ライブラリの作成や原稿が遅れてしまいましたが.••，なんとか書き終える 
ことができました（いやぁ，さすがに右手が使えないとつらいわぁ〜)。 

ライブラリのほうですが，ベースバージョンとしては完成しましたが，高速化 
や関数追加などは，まだまだパソコン通信上でサポートを行うつもりでいますの 
で，レポートなどお待ちしております。また，関数自体は厳しくチェックしたつ 
もりではありますが，なにぶん，関数の数が多いためバグの潜んでいる確率も多 
ございますので...こちらのほうもなにとぞよろしくお願い致します。 

ちなみに，この本の副題は「サルでも書けるライブラリ」です。 

ウゴウゴルーガ生放送のとろりんの「ウゴルーてんきよほう」を見つつ ••• 

- 大西恵司 


0 ったく，とんでもないプロジェクトに首をつっこんでしまったものだと 
思ぅ。 

私が最初にライブラリの作成を始めたのは，あるネットのオフ会でもらってき 
た GNU ソフトの移植をするためだった。こうした UNIX 系のソフトをいわゆ 
る MS-DOS 系に移植するときには，必ずといっていいほど UNIX 側のライブ 
ラリを何とかしなくてはならない。そのため，「どうせ作るならきちんとした仕様 
にあわせよう」との仕様書を買い込んで，ポッリポッリと必要な関数だ 
け形成していった。 

そんなおり，村上氏が NIFTY - Serve でフリーなライブラリを作ろうとしてい 
るという話を耳にした。そのころは，まだこのような書籍という形ではなくネッ 





トワーク上で有志が集まって，皆が作ったライブラリを持ち寄るというものだっ 
た（本文にこのあたりの経緯が述べられている）。そこに私も参加させてもらい， 
今回の書籍化のお手伝いとなった。 

最初は，いままで有志の方々から寄せられたライブラリを基にしていたのだが， 
仕様統一や実用上の問題などを考慮して，一般のプログラマが実用に耐え得るで 
あろう関数仕様としていった。もっとも，作成中にもコンピュータ業界はめまぐ 
るしく変化していったので，当時先進だったものが，今は当たり前のものとなっ 
てしまった。その意味では，従来の純正ライブラリに不満を感じていた方々（また 
は，純正の守備範囲では足りなかった方）には満足していただけると思う。 

今回の書籍化にあたり，企画を取りまとめられた村上氏，ソフトバンクの方々 
にはいろいろとご迷惑をかけたが，辛抱強くサポートしていただき，今こうして 
あとがきを記すことができた。この場を借りて感謝したい。 

また，私にきっかけを投げかけ，数々の助言を与えてくれた方々（誰とはいわな 
いが）にも感謝の言葉を送りたいと思う。 

- 萩野祐二 



局，この本を完成させるのに1年もかかってしまいました（もっとも， 
ずっとかかりっきりだったわけではありませんが..〇。本当はもっと早 
く完成する予定だったのが，いつの間にやらこのありさま。編集の方々にもいろ 
いろと面倒ばかりかけてしまって，まったくもってお恥ずかしいかぎりです。ま 
だまだやり残したことは多いのですが，とりあえずここでひと区切りとします。 


しかし，なんですね。人間，寝なくても結構大丈夫なもんですね （ 「おもいっ 
きし寝とるやんけ」なんてつっこまないように)。おかげさまで，この1年の間 
に，私は寝なくても倒れない方法を体得することができました。もっとも，かの 
翁にいわせれば，まだまだ「寝すぎ」なんでしょうが...。 

そんなことはともかく， X 68030 について。なにしろ， X 68030 が発売され 
たのがちょうど最後の追い込み時期だったので，かの翁はともかく，私自身はあ 
まり X 68030 についてよく調べていません。 187cm さんから X 68030 をお借り 
して一応動くようにはしたものの， X 68030 に対する ZJ 及 C の対応は，はっきり 


いってまだ満足できるものではありません ( X 68030 というよりも Human 68 k 
が ver.3 になったことが大きいのよ...結局のところ）。そこのところは，これか 
らということで大目に見てやってください。 


と，いうわけで皆さん ， Have a nice hacking !! (tK ••「バグ があったら直して 
ちようだい」） 


村上敬一郎 






後に，デバッグやレポ-卜をしてくれた皆さん，どうもありがとうござ 
いました。特に次の方々にはたいへんお世話になりましたので，この場 
を借りてお礼申し上げます。 


Abechan , 板垣さん， 187 cm , 沖@沖さん， TomY さん，ちゃぶにさん， 
homy さん， Bun. さん， Mad Player さん，真里子さん， PEKIN-NET の 
皆さん，そして謎の Mailing List x 6 user の皆さん。 

また， Human68k の解析は PEKIN - NET にアップロードされていた，謎の 
“書籍が出ないのなら自分で書いてしまえプロジェクト’’さんの書いた解析デー 
夕を基に作成しました。このデータは，ライブラリ作成時にもたいへん参考にな 
りました。どうもありがとうございました。 



I 
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